um estudo sobre os aspectos teoricos e pr aticos de teste...
TRANSCRIPT
Um estudo sobre osaspectos teoricos epraticos de teste de
software
Andre Vinıcius Mendes Dela Bandera,Davison Andre Zangerolami de Oliveira,
Jucimara Neves da Silva
Trabalho de Conclusao do Curso
Orientacao: Prof. Dra. Debora Maria Barroso Paiva
Area de Concentracao: Engenharia de Software
dct ufms
Departamento de Computacao e EstatısticaCentro de Ciencias Exatas e Tecnologia
Universidade Federal de Mato Grosso do Sul11 de dezembro de 2008
dct-ufms
2
dct-ufms
Agradecimentos
Em primeiro lugar, a Deus por todas as coisas que aconteceram na nossa vida e que nospermitiram ser o que somos hoje.
Aos nossos pais, pela motivacao, suporte e exemplo que nos deram.
Aos nossos namorados, pelo incentivo, paciencia e companhia em todos os momentos.
A orientadora, por toda ajuda, paciencia e orientacao que nos deu durante esse ano.
A todos os nossos amigos que sempre nos deram apoio.
3
Resumo
O processo de teste no desenvolvimento de sistemas nao e uma tarefa trivial, poisrequer tempo e pessoas que estejam preparadas para testar. O teste, como qualquer outroprocesso, deve ser revisto e melhorado continuamente, de forma a ampliar sua atuacao.Ele garante diminuira os defeitos nas partes que foram testadas, exercendo um papelfundamental na garantia de qualidade do software.
Em relacao as tecnicas de teste, pode ser citado o teste de caixa branca, que avaliao comportamento interno do componente de software ou ainda o teste de caixa preta,em que o componente de software a ser testado e abordado como se fosse uma caixapreta. Neste tipo de teste, nao se considera o comportamento interno do mesmo, e sim asentradas e saıdas. As tecnicas de teste podem ser utilizadas nas fases de desenvolvimentodo teste unitario, integracao, sistema e aceitacao.
A fase de teste unitario e aplicada continuamente no processo de desenvolvimento deum software e e esta fase que e enfatizada neste trabalho. De forma geral, o objetivo destetrabalho e realizar um estudo teorico sobre testes de software, fazer um levantamento dasprincipais ferramentas disponıveis atualmente para auxiliar a execucao de teste de softwaree, com essas ferramentas, realizar um estudo pratico. Para a execucao do trabalho, foiconstruıdo um plano de teste que, quando integrado com as ferramentas JUnit, Eclemmae Metrics, proporcionou um processo de teste unitario automatizado. Os resultados obtidosa partir deste estudo foram aplicados em um projeto real que esta sendo desenvolvido poruma empresa da cidade de Campo Grande.
dct-ufms
Abstract
System development process testing is not an ordinary task since it requires timeand trained personal ready for such tests. Testing, as any other process in IT, should bereviewed and improved continually in order to extend the area in which it is effective, toenlarge the area of its action. It will decrease the errors in the tested parts, exercising afundamental role ensuring software quality.
There are two testing techniques: the white box testing, which evaluates the softwarecomponent’s internal behavior, and the black box testing, in which the software componentto be tested is approached as if it was a black box. The last type does not take intoaccount the software component but inputs and outputs. Both techniques can be used inthe following phases: unitary, integration, system, and acceptance testing.
The unitary testing is carried out continually throughout the software developmentprocess. This is the phase we emphasized in this project. In general terms, our objective isto elaborate a theoretical study about software testing, discuss the main available tools inthe area and their execution – the practical study. To accomplish such goal, we built up atesting plan that, once integrated with the tools JUnit, Eclemma, and Metrics, providedan automated unitary test. The results were applied to a real project which has beencarried out by a private company in Campo Grande.
2
Conteudo
1 Introducao 6
1.1 Visao Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Contextualizacao e Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Verificacao e Validacao 9
2.1 Inspecao de programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Analise estatica automatizada . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Cleanroom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Teste de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.1 Teste de caixa branca . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.2 Teste de caixa preta . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Estrategias de teste de software . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.1 Teste de unidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.2 Teste de integracao . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.3 Teste de validacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.4 Teste de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.1 Apodora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6.2 Check 22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6.3 Continuous Teste para Eclipse . . . . . . . . . . . . . . . . . . . . . 21
1
Conteudo dct-ufms
2.6.4 CSUNIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.5 CUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.6 CUTEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.7 Dave’s Unit Test (DUT) . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.8 DBFeeder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.9 DejaGNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6.10 ECLEMMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6.11 IBM Rational Functional Tester . . . . . . . . . . . . . . . . . . . . 25
2.6.12 ISPIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6.13 JavaTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6.14 Jemmy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6.15 JF-UNITTEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.6.16 JSTester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.6.17 JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.6.18 Marathon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6.19 METRICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6.20 QTUNIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6.21 SELENIUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6.22 Utex (Unit Test Expert for Delphi) . . . . . . . . . . . . . . . . . . 29
2.6.23 XmlMessageTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3 Estudo pratico 33
3.1 Processo de teste unitario . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.1 Processo para realizacao de teste unitario . . . . . . . . . . . . . . . 34
3.1.2 Casos de teste utilizando ferramentas . . . . . . . . . . . . . . . . . 34
3.1.3 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.4 JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1.5 Eclemma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2
Conteudo dct-ufms
3.2 Primeiro Caso Pratico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3 Segundo Caso Pratico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4 Licoes Aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4 Conclusao 65
3
Lista de Figuras
2.1 Distribuicao dos esforcos durante o desenvolvimento do software. (Press-man, 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Modelo V descrevendo o paralelismo entre as atividades de desenvolvimentoe de teste de software (Craig and Jaskiel, 2002). . . . . . . . . . . . . . . . 11
2.3 Exemplo de como contruir um grafo de fluxo (Paiva, 2008). . . . . . . . . . 15
2.4 Figura exemplificando as fases de projeto de software e sua ligacao comtodo o processo de teste (Pressman, 2007). . . . . . . . . . . . . . . . . . . 18
3.1 Desmonstrando a importancia da linguagem Java (Tiobe). . . . . . . . . . 35
3.2 Resultado da analise com a ferramenta Metrics para o metodo corCarro. . 37
3.3 Display da ferramenta JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4 Display da ferramenta Eclemma . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5 Display da ferramenta Eclemma . . . . . . . . . . . . . . . . . . . . . . . . 39
3.6 Figura exemplificando o resultado da execucao do Eclemma, alcancando100% de cobertura das linhas . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.7 Figura exemplificando modelo de relatorio gerado pelo caso de teste aluno,utilizou-se o Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.8 Figura exemplificando modelo de relatorio gerado pelo caso de teste aluno,utilizou-se o Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.9 Figura exemplificando o resultado da execucao do Eclemma, alcancando100% de cobertura das linhas . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.10 Figura exemplificando modelo de relatorio gerado para o caso de uso ManterDistrito, utilizou-se o Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.11 Figura exemplificando modelo de relatorio gerado para o caso de uso ManterDistrito, utilizou-se o Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4
Lista de Tabelas
2.1 Tabela de ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5
Capıtulo 1
Introducao
1.1 Visao Geral
A crescente demanda por software deve-se ao fato de que hoje as empresas se veemobrigadas a modificar a maneira na qual prestam servicos ao cliente e realizam suastarefas. E necessaria a automatizacao de tarefas e de atividades para que assim possamoferecer maior credibilidade, robustez e qualidade nos servicos prestados aos clientes.
Logo, a intencao e melhorar a qualidade do software que esta sendo desenvolvido eentregue ao mercado consumidor. Para realizar esta melhoria, e preciso organizar, planejare medir de forma eficiente e confiavel para que o software possa realmente ser consideradode boa qualidade. E nesse contexto que se insere a fase de testes, a qual tem o papel deverificar, validar e medir o nıvel de qualidade do produto que esta sendo desenvolvido,note que a fase de teste nao e a unica a qualificar a qualidade do software.
1.2 Contextualizacao e Motivacao
Diversas empresas do ramo tecnologico estao voltadas para o desenvolvimento de softwarecom o objetivo de automatizar processos em geral, por exemplo, industrias de automoveis,de avioes etc. De forma geral, a maioria das empresas, principalmente as de pequenoporte, nao esta encarando com preocupacao o processo de construcao de um software,ou seja, continuam desenvolvendo sem o mınimo de planejamento das etapas e metas aserem cumpridas e ainda sem a utilizacao de um processo robusto e consolidado (Angelo,2006). Os motivos pelos quais esse fenomeno esta ocorrendo sao muitas vezes a faltade verbas, os impostos que encarecem o custo de producao, ou ate mesmo a falta decomprometimento do cliente em validar e cobrar um software que atenda a todas asnecessidades pre-estabelecidas. Enfim, o produto final construıdo e afetado fortementepor esse processo falho de desenvolvimento. Quando o prazo para desenvolvimento desoftware e esgotado antes que o processo de desenvolvimento seja finalizado, na maioria
6
1.3. Objetivo dct-ufms
dos casos, o primeiro a perder espaco dentro do processo e a fase de teste. Porem, narealidade, a grande falha das empresas esta exatamente no momento quando se decideretirar ou realizar de forma superficial a fase de testes ja que, como e abordado adiante,o teste e um processo crucial para que o software conquiste o resultado esperado e sejavisto com bons olhos pelas partes interessadas em sua utilizacao.
Diversas empresas nacionais e multinacionais ja comecaram a enxergar a importanciada fase de testes e ja estao aplicando as atividades relacionadas em todas as fases dodesenvolvimento. Muitas pessoas e empresas encaram o teste de um software como sendoum processo que ira trazer resultados negativos, pois este ira encontrar problemas e erros.Na realidade, o teste de software deveria ser visto como uma atividade primordial paraque o software em construcao nao venha a ser prejudicial para aqueles que forem utiliza-lo.
Este trabalho teve duas principais motivacoes: primeiramente, com a grande demandapor software no mercado, uma questao que surgiu foi: “Qual o nıvel de qualidade dossoftwares que estao sendo entregues ao mercado consumidor?”, ou seja, sera que o processode qualidade esta sendo planejado e exercido na pratica? O segundo fator se da por desejarunir o conhecimento adquirido ao longo dos anos na universidade com a realizacao de umestudo pratico tendo como objetivo a verificacao de como deve ser feito o teste de softwaree se as empresas de desenvolvimento dao alguma importancia significativa para a area detestes. Enfim, deseja-se somar experiencia e conhecimento para entao dar continuidade naarea de qualidade de software e, ainda, realizar bons servicos para benefıcio da comunidadetecnologica por meio de pesquisas e estudos voltados para engenharia de software.
1.3 Objetivo
Dentro da engenharia de software, sabe-se que uma das areas menos exercitadas e apli-cadas na pratica e o teste. Segundo uma pesquisa da COMPUTERWORLD (Abramti),publicada na Internet no dia 4 de maio do ano 2006 - 70% das empresas no Brasil adotamBeta Teste. Contudo, ao se olhar mais a fundo essa pesquisa; de 600 leitores que respon-deram a enquete, 36% dizem que testam mas nao levam os testes a exaustao e concordamem dizer que isso poderia levar uma empresa a falencia. Quando uma empresa de tec-nologia inicia um projeto para construcao de um software, todas as etapas deveriam serseguidas de forma que se completassem, para que ao final, seja obtido um produto comqualidade e que deixara seus usuarios satisfeitos. Na pratica, sao poucas as empresas queseguem algum modelo de desenvolvimento para obter excelencia no resultado do produtodesenvolvido.
A partir desse cenario falho, tem-se como objetivo estudar a area de teste de softwarede forma a adquirir conhecimento teorico e pratico, estabelecendo assim um contato euma visao mais proximos de como deve ser o processo de desenvolvimento de um softwarena pratica. De forma mais especıfica, os objetivos deste trabalho sao:
• Realizar um estudo teorico sobre testes de software, de forma a complementar oconhecimento adquirido nas disciplinas cursadas na graduacao.
7
1.3. Objetivo dct-ufms
• Fazer um levantamento das principais ferramentas disponıveis atualmente para au-xiliar a execucao de teste de software, identificando o tipo de teste a que estaoassociadas.
• Realizar um estudo pratico em um projeto real de uma empresa, realizando o dia-gnostico de como a atividade de teste e realizada, propondo melhorias ao processoe colocando em pratica o processo identificado a partir do estudo teorico.
8
Capıtulo 2
Verificacao e Validacao
Verificacao e Validacao (“ V & V ”) e o agrupamento de tecnicas utilizadas para o mel-horamento de todo o ciclo de construcao do software, ou seja, um grupo de tecnicas quetraga um bom funcionamento conforme as especificacoes previas e ainda atendendo asnecessidades do cliente ao termino da construcao do software. O planejamento dos testespode ocorrer em diferentes nıveis e em paralelo ao desenvolvimento do software (Pressman,2007).
Normalmente, uma organizacao que se preocupa com a qualidade do software quedesenvolve gasta de 30% a 40% de esforco na atividade de teste de software e depuracaode software como pode ser visto na Figura 2.1 (Pressman, 2007). Por este motivo, talatividade torna-se muito importante no desenvolvimento e principalmente na qualidadede um software.
Figura 2.1: Distribuicao dos esforcos durante o desenvolvimento do software. (Pressman,2007).
9
dct-ufms
O objetivo dos testes e encontrar diferentes classes de erro com tempo e esforcomınimo, e assim, um teste somente sera considerado de sucesso se for encontrado al-gum tipo de erro (Pressman, 2007). E importante saber que a atividade de teste nao podemostrar a ausencia de bugs, ela so pode mostrar se defeitos estao presentes no software.
Para a maioria dos sistemas, programadores assumem a responsabilidade pelo testede seu proprio codigo (modulos ou objetos). Uma vez concluıdo, o trabalho e passado parauma equipe de integracao, que integra os modulos de diferentes desenvolvedores, constroi osoftware e testa o sistema como um todo. Contudo, caso de sistemas crıticos, um processomais formal pode ser utilizado, quando testadores independentes sao responsaveis portodas as fases do processo de teste (Sommerville, 2005).
Nas secoes seguintes, sao apresentadas as tecnicas de verificacao e validacao, porexemplo, a inspecao, a analise estatica automatizada, cleanroom e o teste de software.Tambem serao apresentadas as estrategias de testes, como o teste de caixa branca e pretae suas formas de abordagem.
Algumas caracterısticas do modelo em V para planejamento e projeto de testes sao,como pode ser visto na Figura 2.2:
1. Inicialmente e planejado o teste de aceitacao a partir do documento de requisitos;
2. Apos esse primeiro teste de aceitacao, e planejado o teste de sistema a partir doprojeto de alto nıvel do software;
3. Em seguida, ocorre o planejamento dos testes de integracao a partir do projetodetalhado;
4. E, por fim, vem o planejamento dos testes a partir da codificacao.
E importante ressaltar que a execucao do plano de teste ocorre no sentido inverso doprojeto do software.
10
2.1. Inspecao de programa dct-ufms
Figura 2.2: Modelo V descrevendo o paralelismo entre as atividades de desenvolvimentoe de teste de software (Craig and Jaskiel, 2002).
2.1 Inspecao de programa
As inspecoes sao revisoes cujo objetivo e a deteccao de defeitos na documentacao dosoftware ou no codigo fonte, e sao feitas por uma equipe, que pode ser de no mınimo 4pessoas, com membros que apresentem diferentes experiencias (Sommerville, 2005). Antesde um programa de inspecoes comecar, e essencial que:
1. Haja uma especificacao precisa do codigo a ser inspecionado. E impossıvel ins-pecionar um componente com o nıvel de detalhes necessario para detectar defeitossem ter uma especificacao completa;
2. Os membros da equipe de inspecao estejam familiarizados com os padroes organi-zacionais;
3. Exista uma versao do codigo disponıvel que esteja atualizada e sintaticamente cor-reta. Nao ha razao para inspecionar codigo que esteja quase completo, e melhoresperar o termino da codificacao, mesmo que um atraso provoque uma interrupcaono cronograma.
Nao e necessario que o software seja executavel para se realizar as inspecoes, assim,inspecoes podem ser utilizados como uma tecnica de verificacao antes que os programassejam implementados. As inspecoes provaram ser uma tecnica eficaz de deteccao de erros,na qual estes podem ser encontrados a um custo menor. Revisoes e testes nao sao tecnicasconcorrentes de V & V. Eles tem suas proprias vantagens e desvantagens e devem serutilizadas em conjunto.
11
2.2. Analise estatica automatizada dct-ufms
Em relacao a equipe de inspecao, ha sempre o moderador, o qual fica responsavelpelo planejamento da inspecao. Isso envolve selecionar uma equipe de inspecao, organizaruma sala de reunioes e garantir que o material a ser inspecionado e suas especificacoesestejam completas. Nesse caso, a inspecao deve ser relativamente curta e deve se ocupar,exclusivamente, em identificar defeitos, anomalias e nao-conformidades com padroes. Aequipe de inspecao nao deve sugerir como esses defeitos devem ser corrigidos, nem re-comendar modificacoes em outros componentes. Em seguida a inspecao, o programa emodificado pelo seu autor, de forma a corrigir os problemas identificados. No estagio deacompanhamento, o moderador deve decidir se uma nova inspecao do codigo e necessaria.O processo de inspecao tambem pode ser dirigido por uma checklist de erros comuns dosprogramadores. Ela deve ser estabelecida em uma discussao entre o pessoal experiente eprecisa ser regularmente atualizada, a medida que maior experiencia seja adquirida como processo de inspecao.
2.2 Analise estatica automatizada
Os analisadores estaticos de programa sao ferramentas de software que analisam o codigofonte de um programa e detectam possıveis defeitos e anomalias. Esta tecnica pode serrealizada a partir do momento que se tem algum codigo fonte, eles nao requerem que oprograma seja executado. Em vez disso, percorrem o texto do programa e reconhecem osdiferentes tipos de declaracoes, tais como variaveis que sao utilizadas sem inicializacao,variaveis que nao sao utilizadas, dados cujos valores podem exceder limites, etc (Som-merville, 2005). Os estagios envolvidos na analise estatica incluem:
• Analise de fluxo de controle: esse estagio identifica e destaca loops com multiplospontos de saıda ou de entrada e codigo inacessıvel;
• Analise da utilizacao de dados: esse estagio ressalta como as variaveis no programasao utilizadas. Ele detecta variaveis que sao utilizadas sem previa inicializacao,variaveis que sao escritas duas vezes sem uma tarefa de impedimento e variaveisque sao declaradas mas nunca sao utilizadas. A analise do uso de dados tambemdescobre testes ineficientes em que a condicao de testes e redundante;
• Analise de interface: essa analise verifica a consistencia das declaracoes de rotina, dosprocedimentos e seus usos. Ela tambem pode detectar funcoes e procedimentos quesao declarados e nunca chamados, ou resultados de funcoes que nunca sao utilizadas;
• Analise do fluxo de informacoes: essa fase da analise identifica as dependencias entreas variaveis de entrada e as variaveis de saıda. Pode tambem mostrar as condicoesque afetam um valor da variavel.
• Analise de caminho: essa fase da analise semantica identifica todos os caminhospossıveis no programa e exibe as declaracoes executadas nesse caminho.
12
2.3. Cleanroom dct-ufms
A analise com base em ferramentas nao pode substituir as inspecoes, uma vez que exis-tem alguns tipos de erros que os analisadores estaticos nao podem detectar, pois focamem declaracoes de variaveis e fluxo de controle do programa e acrescentam vantagensjuntamente com o compilador da linguagem em questao.
2.3 Cleanroom
O Cleanroom e uma filosofia de desenvolvimento de software que tem como base evitardefeitos de software por meio do uso de um rigoroso processo de inspecao. O objetivo dessaabordagem e conseguir um software sem defeito algum (Sommerville, 2005). A abordagemCleanroom apresenta cinco caracterısticas principais:
1. Especificacao formal: o software a ser desenvolvido e formalmente especificado.Utiliza-se um modelo de transicao de estado que mostra as respostas do sistemaa estımulos de forma a expressar essa especificacao.
2. Desenvolvimento incremental: o software e decomposto em incrementos, os quaissao desenvolvidos e validados separadamente, utilizando-se o processo Cleanroom.Esses incrementos sao especificados, com a entrada do cliente, em um estagio inicialdo processo;
3. Programacao estruturada: e utilizado somente um numero limitado de construcoesabstratas de controle e de dados. O desenvolvimento do programa e um processo derefinamento da especificacao formal e e feito passo a passo. Como um numero limi-tado de construcoes e utilizado, a meta e aplicar as transformacoes com preservacaode correcao a especificacao a fim de criar o codigo do programa;
4. Verificacao estatica: o software desenvolvido e verificado estaticamente, utilizando-se rigorosas inspecoes de software. Nao existe nenhum processo de teste de unidadeou de modulo para os componentes de codigo;
5. Teste estatıstico do sistema: o incremento de software integrado e testado estatis-ticamente para determinar sua confiabilidade. Esses testes estatısticos baseiam-seem um perfil operacional, que e desenvolvido em paralelo com a especificacao dosistema.
Portanto, essa filosofia e baseada em estados e e produzida para servir como uma especi-ficacao de sistema e, assim, e refinada por meio de uma serie de diferentes modelos desistema para um programa executavel. A abordagem utilizada para o desenvolvimentotem como base transformacoes bem definidas as quais tentam preservar a exatidao emcada transformacao, de forma a se obter uma representacao mais detalhada. As inspecoesde programa sao suplementadas por argumentos matematicos rigorosos, que demonstramque a saıda da transformacao e consistente com sua entrada.
13
2.4. Teste de software dct-ufms
2.4 Teste de software
Os testes de software devem focalizar as interacoes entre os componentes, as funciona-lidades e o desempenho do sistema como um todo (Pressman, 2007). Inevitavelmente,defeitos em componentes que tenham sido omitidos durante os primeiros testes, sao des-cobertos durante os testes de integracao.
Os testes de integracao, contudo, devem se basear em uma especificacao escrita dosistema, que pode ser uma especificacao detalhada dos requisitos de sistema ou pode seruma especificacao, orientada ao usuario, das caracterısticas que devem ser implementadas(Sommerville, 2005).
Em seguida, sao descritas as tecnicas de teste de software que devem ser abordadasem conjunto, pois, como se sabe, uma completa a outra. Na secao 2.5, sao abordadas asestrategias de teste de software.
2.4.1 Teste de caixa branca
O teste de caixa branca e uma tecnica de projeto de casos de teste que usa a estruturade controle do projeto procedimental para derivar casos de teste. As garantias devem sercumpridas para que esse metodo seja utilizado corretamente, tais quais:
1. Todos os caminhos independentes dentro de um modulo tem que ser exercitadospelo menos uma vez;
2. E necessario que todas as decisoes logicas sejam executadas para valores falsos ouverdadeiros;
3. Todos os lacos em suas fronteiras e dentro de seus limites operacionais devem serexecutados;
4. As estruturas da dados internas devem ser exercitadas de forma a garantir a suavalidade.
Ha duas maneiras de abordar o teste de caixa branca. O primeiro e o teste de caminhobasico, onde se faz um caso de teste que passe por todos os caminhos basicos, testando oslimites do programa. Ele envolve as atividades de notacao de grafo de fluxo, complexidadeciclomatica, derivacao de caso de teste e matriz de grafo, as quais sao descritas a seguir(Pressman, 2007).
A notacao de grafo de fluxo descreve o fluxo de controle logico do codigo, onde osvertices sao os blocos e as arestas os fluxos possıveis do programa. Na Figura 2.3 segueum exemplo da construcao de um grafico de fluxo. A complexidade ciclomatica e umametrica de software que pode ser usada em conjunto com o teste do caminho basico e quenos diz quantos caminhos logicos ha no software. A quantidade de aminhos independentes
14
2.4. Teste de software dct-ufms
e igual a complexidade ciclomatica. Um caminho independente e qualquer caminho atravesdo programa que introduza pelo menos um novo conjunto de instrucoes de processamentoou uma nova condicao. Existem tres metodos para calcular a complexidade ciclomatica: oprimeiro e numero de regioes do grafo e o segundo e definido pela formula V(G) = ramos- nos + 2 e ainda V(G) = P + 1 (onde P sao os nos predicativos do grafo) (Pressman,2007). Na Figura 2.3 a complexidade ciclomatica e 8 - 7 + 2 = 3.
Figura 2.3: Exemplo de como contruir um grafo de fluxo (Paiva, 2008).
Derivando casos de teste, esse tecnica de teste pode ser aplicado a um projeto pro-cedimental ou a um codigo-fonte detalhado, desde que uma serie de passos seja seguida:
1. Usando o projeto ou o codigo como base, trace um grafo de fluxo correspondente;
2. Determine a complexidade ciclomatica do grafo de fluxo resultante;
3. Determine um conjunto basico de caminhos linearmente independentes;
4. Prepare os casos de teste que forcem a execucao de cada caminho no conjunto basico.
Em relacao as decisoes logicas, as matrizes de grafos possuem representacoes quadrati-cas, cujo tamanho e igual ao numero de nos do grafo de fluxo. Cada linha e coluna corres-ponde a um no identificado, e as entradas da matriz correspondem a conexoes entre osnos. Adicionando-se pesos as arestas pode-se avaliar a estrutura de controle do programadurante a fase de teste. Nesse caso, o peso pode significar: a probabilidade de que umaligacao seja executada, o tempo de processamento despendido durante a travessia de umaligacao, a memoria exigida durante a travessia e os recursos exigidos durante a travessia.
Uma outra maneira de abordar o teste de caixa branca e o teste de estrutura decontrole. Para melhorar a qualidade do teste de caixa branca e possıvel aplicar o teste de
15
2.4. Teste de software dct-ufms
estrutura de controle, que amplia a cobertura dos testes. Este teste envolve as seguintesatividades: teste de condicao, teste de fluxo de dados e teste de lacos (loops). A seguirdescreve-se cada um deles.
O teste de condicao poe a prova as condicoes logicas contidas num modulo de programae concentra-se em testar cada condicao do programa. As vantagens de se fazer os testesde condicoes sao que a medicao de cobertura de tal teste e simples e a cobertura de testedas condicoes de um programa oferece orientacao para geracao de testes adicionais parao programa. Incluem-se os seguintes tipos de erro de uma condicao:
1. Erro de operador booleano ( a existencia de operadores booleanos incorretos/faltan-do/extras);
2. Erro de variavel booleana;
3. Erro de parentese booleano;
4. Erro de operador relacional;
5. Erro de expressao aritmetica.
A condicao simples e uma variavel booleana ou expressao relacional, possivelmenteprecedida por operador NOT(‘). A expressao relacional tem a forma: E1 <operadorrelacional> E2 , em que os operadores sao os ja conhecidos. Ja a expressao booleanae uma condicao sem expressao relacional. Alem disso, o proposito do teste de condicao edetectar erros nas condicoes de um programa e no programa.
Outros testes de caixa branca sao: teste de Ramos, em que todas as condicoes simplesprecisam ser executadas pelo menos uma vez; teste de Domınio, o qual requer que tres ouquatro testes sejam derivados para uma expressao relacional; teste de fluxo de dados, queseleciona caminhos de teste de um programa de acordo com as localizacoes da definicoese usos de variaveis no programa e teste de lacos (loops), o qual e uma tecnica que seconcentra exclusivamente na validade das construcoes de lacos. Classes de lacos sao oslacos simples, concatenados, aninhados e nao-estruturados.
Um problema relacionado ao teste estrutural e a impossibilidade, em geral, de sedeterminar automaticamente se um caminho e ou nao executavel, ou seja, nao existe umalgoritmo que dado um caminho completo qualquer decida se o caminho e executavele forneca o conjunto de valores que causam a execucao desse caminho (Barbosa et al.,2004).
2.4.2 Teste de caixa preta
Este teste concentra-se nos requisitos funcionais do software. Ele possibilita que o enge-nheiro de software derive conjuntos de condicoes de entrada que exercitem completamentetodos os requisitos funcionais de um programa. Alem disso, descobre erros das seguintescategorias:
16
2.4. Teste de software dct-ufms
• Funcoes incorretas ou ausentes;
• Erros de interface;
• Erros nas estruturas de dados ou no acesso a bancos de dados externos;
• Erros de inicializacao e termino.
Ha quatro maneiras de abordar o teste de caixa preta, que sao: o particionamento deequivalencia, a analise de valor limite, as tecnicas de grafos de causa-efeito e os testes decomparacao.
Particionamento de equivalencia e um metodo de teste de caixa preta que divide odomınio de entrada de um programa em classes de dados a partir das quais os casos deteste podem ser derivados, descobrindo assim classes de erro e diminuindo o numero decasos de teste que devem ser desenvolvidos. Conforme uma condicao de entrada, que podeser valida ou invalida, desenvolvem-se os seguintes testes:
1. Se uma condicao de entrada especificar o intervalo, ou um valor especıfico, escolhe-seuma classe de equivalencia valida e duas invalidas;
2. Se uma condicao de entrada especificar um conjunto ou for booleana: escolhe-se umaclasse de equivalencia valida e uma invalida.
Como ocorrem mais erros na fronteira (valor limite) do que no “centro”, sao realizadostestes nessas regioes. Para completar a analise de valor limite os teste de particionamentode equivalencia, devem ser avaliados:
1. Intervalo a e b, em que os testes devem ser feitos logo acima e logo abaixo de a e b;
2. Sao testadas uma serie de valores de numeros logo abaixo e logo acima do mınimoe maximo;
3. Aplica-se um e dois as condicoes de saıda;
4. Exercita-se a estrutura de dados em sua fronteira.
Testes de comparacao sao uma tecnica de caixa preta desenvolvida para softwareconsiderado de confiabilidade absolutamente crıtica, como os softwares de avioes. Paraminimizar os erros em tais softwares, pode-se desenvolver um software redundante. Nostestes, as versoes sao executadas em paralelo assegurando a consistencia do sistema crıtico.Quando multiplas implementacoes da mesma especificacao sao produzidas, faz-se o testeda caixa preta e se verifica se as saıdas sao iguais, podendo este teste ser automatizado.Esse teste nao e infalıvel, pois se um programa estiver errado, ele refletira nos outros.
Tecnica de grafos de causa-efeito e uma tecnica de projeto de casos de teste que ofereceuma representacao concisa das condicoes logicas e das acoes correspondentes. Essa tecnicaenvolve as seguintes atividades:
17
2.5. Estrategias de teste de software dct-ufms
• Causas (condicoes de entrada) e efeitos (acoes) sao relacionados para um modulo eum identificador e atribuıdo a cada um;
• Um grafo de causa-efeito e desenvolvido;
• O grafo e convertido numa tabela de decisao;
• As regras da tabela de decisao sao convertidas em casos de teste.
Um dos problemas relacionados aos criterios funcionais e que muitas vezes a especi-ficacao do programa e feita de modo descritivo e nao formal. Dessa maneira, os requisitosde teste derivados de tais especificacoes sao tambem, de certa forma, imprecisos e infor-mais (Barbosa et al., 2004).
E importante ressaltar que as tecnicas de teste devem ser utilizadas de forma a secomplementarem e a questao esta em como utiliza-las de forma que as vantagens de cadauma sejam melhor exploradas em uma estrategia de teste que leve a uma atividade deteste de boa qualidade, ou seja, eficaz e de baixo custo (Barbosa et al., 2004).
2.5 Estrategias de teste de software
Para se construir um software de qualidade, e preciso planejar, projetar, executar e avaliaro teste. A Figura 2.4, ilustra como pode ser executado um projeto de teste. Primeiramente,deve-se ter o codigo fonte do projeto para que sejam aplicados os testes de unidade.Quando terminam esses testes, inicia-se a fase de integrar o projeto e fazer os respectivostestes de integracao. Apos essa fase, sao realizados os testes de validacao utilizando odocumento de requisitos. Com a conclusao destes ultimos testes, comecam os testes desistema que poe a prova todos os aspectos do sistema.
Figura 2.4: Figura exemplificando as fases de projeto de software e sua ligacao com todoo processo de teste (Pressman, 2007).
18
2.5. Estrategias de teste de software dct-ufms
2.5.1 Teste de unidade
O teste de unidade (ou unitario) e um tipo de teste em que se concentram os esforcosnas menores unidades do software desenvolvido, ou seja, testa-se cada modulo do sistema,visando testar os pequenos trechos de codigo ou ate mesmo metodos. Isso e feito paraque se tenha garantia de que eliminando os pequenos erros, evitar-se-a erros maiores nofuturo, os quais consumiriam muito mais recursos do projeto. Alem disso, tal teste podeser aplicado quando ja houver codigo fonte disponıvel, e apos o termino e possıvel partirpara o teste de integracao. De acordo com Pressman, “Sao exigidos testes de fluxo dedados ao longo da interface de um modulo antes que qualquer outro teste seja iniciado. Seos dados nao entrarem e saırem adequadamente, todos os demais testes serao discutıveis”(Pressman, 2007).
2.5.2 Teste de integracao
Nessa fase, faz-se a construcao da estrutura do programa e, em conjunto, executam-seos testes para descobrir erros nas interfaces. O objetivo de tal teste e procurar falhas naintegracao dos modulos. Assim, o software e testado em pequenas partes, pois a integracaoe incremental e dessa forma e mais facil isolar e corrigir o erro. Em geral, as falhas saoencontradas no envio e no recebimento de dados, por exemplo, quando um metodo einvocado recebendo o valor “A”, ele deveria retornar o valor “B”, mas retorna o valor“C”, o que caracteriza uma falha.
A integracao dos modulos e feita utilizando dois tipos de metodologia, sao elas: aintegracao Top-Down e a integracao Bottom-Up.
A integracao Top-Down e iniciada com a juncao dos modulos de cima para baixo,logo, os modulos subordinados sao integrados aos modulos de controle. Como o processoe feito de forma iterativa, os modulos ainda nao estao prontos e para isto sao utilizadosstubs, os quais substituem os modulos subordinados que ainda nao existem. Entretanto,os stubs sao uma desvantagem desse tipo de integracao, pois tem-se que criar um artifıciopara poder usar a metodologia. Por outro lado, e possıvel testar as estruturas de controlelogo no comeco da integracao.
Ja a integracao Bottom-Up e iniciada com a juncao dos modulos de baixo para cima.Assim, os modulos de baixo nıvel sao combinados em clusters, e e possıvel executar umadeterminada subfuncao do software e deve haver drivers para ser possıvel a ligacao entreos modulos. A vantagem dessa metodologia e a facilidade de criacao, pois nao e necessarioa utilizacao de stubs. Porem, o programa nao existe por completo ate a integracao de todoo sistema.
Concluindo, a escolha de qual metodologia usar ira depender inteiramente das carac-terısticas do software, podendo ser utilizada ate mesmo uma abordagem combinada.
19
2.6. Ferramentas dct-ufms
2.5.3 Teste de validacao
Apos o termino dos testes de integracao, o sistema ja esta completamente montado eentao inicia-se a fase de teste de validacao. Tal teste nada mais e do que a verificacao parase determinar se o sistema esta de acordo com o que o cliente especificou, ou seja, se osistema funciona de forma esperada pelo cliente e contenha o princıpio da usabilidade.
Com esse documento em maos, sao feitos testes de caixa preta, os quais demonstrama conformidade com os requisitos. Depois disso, e liberada uma versao do software parao teste alfa. Nesse teste, o cliente ira nas instalacoes do desenvolvedor e testara a versaodisponibilizada com a supervisao do desenvolvedor. Logo que o cliente termine esses testes,os defeitos encontrados sao corrigidos, e outra versao e liberada, a qual sera testada pelosusuarios finais nas instalacoes do cliente. Esse novo teste e conhecido como teste beta.Novamente os problemas serao corrigidos e, assim, termina esta fase.
2.5.4 Teste de sistema
O teste de sistema e feito de forma a por a prova todos os aspectos do sistema. Esse testepode ser subdividido em quatro tipos de abordagens: teste de recuperacao, de seguranca,de estresse, de desempenho e que sao brevemente descritos a seguir.
O teste de recuperacao e um teste em que se forca o sistema a falhar de diferentesformas e depois e verificado se ele foi capaz de se recuperar sem exigir intervencao humana.Por exemplo, se faltar energia no sistema, como este reagira quando a energia voltar.
O teste de seguranca e necessario para que seja verificado se os mecanismos de protecaodo sistema realmente os protegerao de acessos nao autorizados. Por exemplo, um hackertentando invadir um website.
O teste de estresse e realizado criando-se situacoes anormais e verificando-se ate ondeo sistema consegue se adpatar. Por exemplo, o acesso de um site por um numero muitomaior de pessoas do que e esperado.
O teste de desempenho e idealizado para testar o desempenho do software em tempode execucao, ou seja, quando se e acessado um site na internet, precisa-se observar se essesite nao esta demorando muito para carregar, pois o usuario nao gosta de esperar muitotempo.
2.6 Ferramentas
Apos o estudo teorico sobre teste de software, foi feito um levantamento de ferrramentasde teste. Foram analisadas suas funcionalidades, linguagens testadas, tecnicas utilizadase tambem um link onde podem ser encontradas.
20
2.6. Ferramentas dct-ufms
As ferramentas sao muito importantes pois auxiliam e automatizam o processo deteste do software. Foram pesquisadas ferramentas que podem auxiliar e orientar na fasede teste de um sistema em uma empresa.
Sao varias as ferramentas para teste de software. A seguir lista-se algumas dessasferramentas com a finalidade de descrever suas funcionalidades, orientar e oferecer suportepara quem for utiliza-las.
2.6.1 Apodora
Finalidade: Como principais caracterısticas, a ferramenta contribui para obtencao demaior cobertura de testes, facilita a gestao de atividades de teste e melhora a robustezna automacao de objetos no repositorio, com base em IronPython entre outras, ou seja,oferece suporte de forma agil, eficiente e completa para o processo de realizacao dos testesfuncionais. Ao final deste processo e possıvel gerar relatorios afim de documentar as tarefasrealizadas atraves dos testes funcionais.
Outras informacoes podem ser encontradas nos seguintes sites: http://www.apodora.org/\protect\kern+.2777em\relax http://www.apodora.org/tutorial/demo/demo.
html (tutorial) http://sourceforge.net/project/platformdownload.php?group_
id=195859 (download). Data da pesquisa: 29/07/2008.
Ponto de vista: Para aplicacao na web, inicialmente com um grau de desenvolvi-mento razoavel. Possui um vıdeo em ingles como tutorial e ha pouca documentacaodisponıvel.
2.6.2 Check 22
Finalidade: Esse framework serve para testes de unidade para a linguagem C. Ele e similara outros frameworks tal como o JUnit. Possui uma interface simples para a configuracaode testes unitarios, e a apresentacao dos resultados pode ser feita por meio de codigo fontee IDE’s.
Outras informacoes podem ser encontradas nos seguintes sites: http://
sourceforge.net/projects/check/; http://sourceforge.net/project/showfiles.
php?group_id=28255 (download). Data da pesquisa: 29/07/2008.
Ponto de vista: E open source e nao possui documentacao. Depende de outrossoftwares para funcionar. Versao atual: 0.8.4.
2.6.3 Continuous Teste para Eclipse
Finalidade: O software CT-Eclipse e um plugin opensource integrado a IDE Eclipse. Esteaplica e gerencia testes unitarios e ajuda o desenvolvedor a automatizar o teste no codigo.
21
2.6. Ferramentas dct-ufms
Pode-se baixa-lo usando um subversion e, apos o download, decidir usa-lo ou nao em umprojeto Java. Com ele ativado, ha possibilidade de editar seu codigo enquanto o Eclipseaplica seus testes e notifica se algum deles falhar ou causar erros. Alem de usar o eclipse,ele tambem pode ser integrado com o software JUnit facilitando ainda mais os testes.
Outras informacoes podem ser encontradas nos seguintes sites: http://ct-eclipse.tigris.org/; http://ct-eclipse.tigris.org/svn/ct-eclipse/trunkct-eclipse
(download). Data da pesquisa: 28/07/2008.
Ponto de vista: Auxilia no desenvolvimento utilizando a IDE Eclipse e, alem disso,e open source. Porem, a ferramenta apresenta pouca documentacao e somente pode serusada no Eclipse. Versao atual: 4.
2.6.4 CSUNIT
Finalidade: O CSUNIT e uma ferramenta Software Livre para teste de unidade voltadoa tecnologia .NET framework. Possui uma interface grafica de facil utilizacao. A suautilizacao e extremamente simples, sendo que o aprendizado nao leva mais do que 20minutos.
Outras informacoes podem ser encontradas nos seguintes sites: http://www.csunit.org/; http://www.csunit.org/tutorials/index.html (tutorial); http://internode.dl.sourceforge.net/csunit/csUnit.2.5.setup.msi?download (download). Data dapesquisa: 29/07/2008.
Ponto de vista: Pode ser integrado ao JUnit. Nao especifica muito bem, na docu-mentacao, o objetivo da ferramenta e, alem disso, a tecnologia .NET e privada e, portanto,nao acessıvel a todos que desejam utilizar a ferramenta. Versao atual: 2.5.
2.6.5 CUT
Finalidade: CUT (C Unit Tester) e um framework open source que realiza teste unitariopara as linguagens C, C++ e C Objective-C. Para determinadas circunstancias, ele podeser utilizado para realizar testes na linguagem de baixo nıvel “assembly”. Tal frameworkfoi desenvolvido por meio da linguagem C e so pode ser utilizado para linguagens dafamılia C.
Outras informacoes podem ser encontradas nos seguintes sites: http:
//falvotech.com/content/cut/3/; http://www.falvotech.com/content/
cut/repo/stable/docs/tutorials/sergei_gnezdov/Tutorial.pdf (tutorial);http://falvotech.com/content/cut/3/ ( download). Data da pesquisa: 28/07/2008.
Ponto de vista: A ferramenta e amplamente utilizada para teste unitario em codigospara a linguagem C. Possui varias versoes e nenhuma delas possui uma documentacaocompleta. O site oficial fornece uma explicacao breve sobre o funcionamento e o uso.
22
2.6. Ferramentas dct-ufms
Porem, a ferramenta oferece pouca facilidade no uso. Versao atual: 3.0.
2.6.6 CUTEST
Finalidade: CUTEST (C Unit Testing ) e uma biblioteca para a linguagem C que podeser utilizada na metodologia “Extreme Programming” e no teste unitario para programasna linguagem C. O objetivo e garantir que o codigo funcione como esperado, mesmo quecom pequenas alteracoes. Possui ainda depuracao rapida para evitar que se gaste horastentando descobrir onde esta o defeito.
Outras informacoes podem ser encontradas nos seguintes sites: http://
cutest.sourceforge.net/; http://cutest.sourceforge.net/ (tutorial); http://
sourceforge.net/project/showfiles.php?group_id=52240 (download). Data dapesquisa: 23/07/2008.
Ponto de vista: Essa ferramenta segue as mesmas caracterısticas da ferramentaCUT. Tambem apresenta escassez de documentacao e pouca facilidade no uso. Versaoatual: 1.4.
2.6.7 Dave’s Unit Test (DUT)
Finalidade: Esse software e opensource e serve para se fazer testes unitarios em linguagensC ou C++. Mais precisamente, pode-se testar as condicoes booleanas e a existencia deexcecoes. Ele foi testado com varias versoes do compilador gcc e repositorio SVN, ondepara algumas versoes tanto do compilador gcc como tambem para repositorio SVN, houveproblemas de incompatibilidade de versoes com o software.
Outras informacoes podem ser encontradas nos seguintes sites: http://sourceforge.net/project/showfiles.php?group_id=217691; http://sourceforge.net/project/
showfiles.php?group_id=217691\&package_id=262449\&release_id-=582636
(download). Data da pesquisa: 28/07/2008.
Ponto de vista: E opensource e executa testes das condicoes booleanas. A ferra-mentas possui pouca documentacao e nao apresenta garantias de bom funcionamento emtodos subversions e compiladores. Versao atual: 0.8.3.
2.6.8 DBFeeder
Finalidade: O DBFeeder le as informacoes necessarias para realizar os testes diretamentedo banco de dados e, alem disso, contem estruturas que geram automaticamente os dadospara os testes, sendo que esses se encaixam na estrutura da tabela do banco de dados aser testada. O DBFeeder associa cada coluna de cada tabela do usuario em um esquemacom dados de criacao da regra associada a tabela a ser testada.
23
2.6. Ferramentas dct-ufms
Outras informacoes podem ser encontradas nos seguintes sites:fundamento:http://dbfeeder.sourceforge.net/Manual.htm; http://dbfeeder.sourceforge.
net/Tutorial.html(tutorial); http://sourceforge.net/project/showfiles.php?
group_id=173454 (download). Data da pesquisa: 30/07/2008.
Ponto de vista: O teste de banco de dados e a oportunidade de verificar a con-sistencia das informacoes nele contidas, logo o DBFeeder vem suprir as necessidades demanter a corretude e funcionamento do banco de dados. Por fim, profissionais experientescom o uso da ferramenta argumentam nao ser facil a realizacao dos testes mesmo com aajuda e auxılio da ferramenta e esta so testa o banco Oracle. Versao atual: 0.9 beta.
2.6.9 DejaGNU
Finalidade: Ele possui um script chamado runtest principal, que funciona por meio deum repositorio que procura arquivos de configuracao e entao executa alguns testes comcriterios pre-determinados. O objetivo do DejaGNU e fornecer um unico front end paratodos os testes. Trata-se de uma parte do projeto GNU e, como tal, esta sob a GPL. Osatuais mantenedores sao Rob Savoye e Ben Elliston.
O DejaGNU tem uma historia com bastante peso com relacao aos testes devido a suabase Tcl. Tcl e amplamente utilizado por empresas como Oracle e Sybase para testar osseus produtos. Essa ferrramenta permite que tal trabalho seja muito mais estruturado,pois os testes podem ser agrupados de acordo com a ferramenta que estao testando.
Uma area a que se adapta bem ao DejaGNU e a de sistemas embutidos. Ele permitetestar partes do sistema que estao sendo desenvolvidas remotamente. Esse enfoque em sis-temas embutidos e a fonte de sua popularidade em muitos projetos de GNU, universidadese empresas privadas.
Outras informacoes podem ser encontradas nos seguintes sites: http://www.gnu.org/software/dejagnu/; http://www.gnu.org/software/dejagnu/#documentation (tuto-rial); http://www.gnu.org/software/dejagnu/#downloading (download). Data dapesquisa: 30/07/2008.
Ponto de vista: A documentacao e bem elaborada, auxiliando muito na utilizacao.Pode ser utilizado com outras ferramentas, e seu pre-requisito e estudar GNU. Versaoatual: 1.4.4.
2.6.10 ECLEMMA
Finalidade: O EclEmma e uma ferramenta livre, de cobertura do codigo Java para oeclipse, estando disponıvel sob a licenca do publico do eclipse. A preocupacao principal daferramenta e verificar se o codigo do teste unitario esta bem implementado, ou seja, muitasvezes pode-se estar realizando testes duplicados em metodos ou nao estar realizandoteste em outros. O EclEmma nao tem como objetivo encontrar erros e sim em orientar o
24
2.6. Ferramentas dct-ufms
utilizador para falhas no desenvolvimento do software.
Outras informacoes podem ser encontradas nos seguintes sites: http:
//sourceforge.net/projects/eclemma; http://www.vieirajunior.com/index.
php?option=com_content\&task=view\&id=56\&Itemid=65 (tutorial); http:
//sourceforge.net/projects/eclemma (download). Data da pesquisa: 13/08/2008.
Ponto de vista: Essa ferramenta proporciona mais uma forma de aumentar a quali-dade do sistema, alem de proporcionar uma maneira de tentar identificar partes do sistemaque ainda nao foram testadas e precisam ser testadas. Versao atual: Beta.
2.6.11 IBM Rational Functional Tester
Finalidade: O Rational Functional Tester e uma ferramenta de teste automatizada orien-tada a objetos que testa aplicativos do Windows, .Net, Java, HTML, Siebel, SAP, AJAX eFlex. Ele permite a gravacao de scripts confiaveis e consistentes que podem ser reproduzi-dos para validar novas construcoes de um aplicativo em teste. O Functional Tester podeser executado em sistemas operacionais Microsoft Windows 2000, Windows XP, WindowsVista e Linux. Alem disso, essa ferramenta esta disponıvel em dois ambientes de desen-volvimento integrado e em duas linguagens de script. Sao eles, o primeiro FunctionalTester Java Scripting que utiliza a linguagem Java e o IBM Rational Software Deliv-ery Platform, o segundo Functional Tester VB.NET Scripting que utiliza a linguagemVB.NET e o ambiente de desenvolvimento Microsoft Visual Studio .NET.
Outras informacoes podem ser encontradas nos seguintes sites: http:
//www.ibm.com/developerworks/rational/library/06/1205_kelly/; http:
//download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/rft/701/
docs/readme/html/pt_BR/readme_701.html (tutorial). Data da pesquisa: 28/07/2008.
Ponto de vista: A ferramenta ja esta consolidada no mercado de trabalho. Possuiuma integracao vasta com outras ferramentas de desenvolvimento de software e docu-mentacao disponıvel de boa qualidade para duvidas e explicacoes em geral sobre a ferra-menta. A ferramenta e particular e nao esta disponıvel para utilizacao gratuita. Versaoatual: 7.0.
2.6.12 ISPIS
Finalidade: O ISPIS (Infra-estrutura Computacional para Apoiar o Processo de Inspecaode Software) e uma ferramenta que possui a funcao de auxiliar na inspecao de software.Essa ferramenta visa apoiar a reorganizacao do processo de inspecao. Entretanto, o ISPISfoi desenvolvido utilizando uma metodologia experimental, levando em consideracao oconhecimento a respeito de inspecoes de software selecionado criteriosamente e dandopreferencia a conhecimento efetivamente avaliado. O ISPIS e a unica ferramenta quepossibilita o uso automatizado deste conhecimento sem que a equipe de inspecao preciseadquiri-lo por meio de revisoes nos requisitos e aplica-lo manualmente.
25
2.6. Ferramentas dct-ufms
Outras informacoes podem ser encontradas nos seguintes sites: http:
//lens-ese.cos.ufrj.br/ese/index.php?option=com_docman\&task=doc_details\
&gid=4\&lang=pt_br; http://lensese.cos.ufrj.br/ese/index.php?option=com_
docman\&task=doc_download\&gid=4\&lang=pt_br (download). Data da pesquisa:28/07/2008.
Ponto de vista: A ferramenta tem ainda sido utilizada para a realizacao de projetosna industria. Por representar o estado da arte a respeito de inspecoes de software, o ISPISresultou em artigos cientıficos apresentados em conferencias renomadas. Sua aplicabilidadena industria permitiu ainda publicacoes sob forma de relatos de experiencia.
2.6.13 JavaTT
Finalidade: JavaTT e uma ferramenta open source para testar aplicacoes Java. Ela podeexecutar varios tipos de testes em sua aplicacao Java: testes de caixa preta e de caixabranca (testes sobre a aplicacao logica sob a interface grafica do usuario).
Outras informacoes podem ser encontradas nos seguintes sites: http://javatt.
com/en; http://javatt.com/en/documentation_javatt_0.6.php (tutorial); http://
javatt.com/en/download.php (download). Data da pesquisa: 04/08/2008.
Ponto de vista: Muito interessante pois se aplica a teoria que e estudada (caixa pretae branca), na aplicacao dos testes. E especıfica para a linguagem Java, como a maioriadas ferramentas. Versao atual: 0.6.
2.6.14 Jemmy
Finalidade: Os testes sao realizados em programas Java. Jemmy representa o caminhomais natural para testar Java UI (executar o teste logo a partir do codigo Java). Essaferramenta e uma biblioteca Java que fornece clareza e simplicidade de acesso a API JavaUI. Os testes sao programas implementados na linguagem Java que utilizam as bibliotecasdisponıveis na linguagem. Apos os testes em Java, e permitido utilizar toda a flexibilidadede alto nıvel para capturar testes na linguagem logica e tambem fazer quaisquer outrasoperacoes necessarias para ser possıvel realizar os testes automatizados. O proprio Jemmyfornece todas as APIs necessarias para se escrever testes em termos de componentes JavaUI (AWT e Swing).
Outras informacoes podem ser encontradas nos seguintes sites: http://
jemmy.netbeans.org/; http://jemmy.netbeans.org/tutorial.html (tutorial); http://jemmy.netbeans.org/downloads.html (download). Data da pesquisa: 30/07/2008.
Ponto de vista: A documentacao e bem elaborada, o que e de muita valia na uti-lizacao. Nao e uma ferramenta, mas sim uma biblioteca.
26
2.6. Ferramentas dct-ufms
2.6.15 JF-UNITTEST
Finalidade: O JF-UNITTEST C++ e um framework que realiza testes unitarios. Ele foidesenvolvido, apos varias frustracoes com ferramentas para teste unitario existentes nomercado anteriormente a essa. Esta ferramenta nao contem qualquer GUI colorida combarras de progresso.
Outras informacoes podem ser encontradas nos seguintes sites: http:
//confix.sourceforge.net/; http://sourceforge.net/project/showfiles.php?
group_id=68975\&package_id=259637\&release_id=578450 (download). Data dapesquisa: 23/07/2008.
Ponto de vista: Falta de documentacao, pouca facilidade na utilizacao e falha nasexplicacoes praticas da ferramenta. Versao atual: 1.0.1.
2.6.16 JSTester
Finalidade: O JSTester permite a validacao do codigo JavaScript dentro do desenvolvi-mento de software que utiliza a linguagem Java. Ela fornece um grupo de metodos assertdo JUnit Assert. Com essa ferramenta, tem-se duas formas de criacao dos testes: Heranca(JsTestCase) e Composicao (JsTester). O ponto de partida do projeto foi a necessidadede testar JSON codigo gerado por JSON-lib.
Outras informacoes podem ser encontradas nos seguintes sites: http://jstester.sourceforge.net/; http://javatt.com/en/documentation_javatt_0.6.php (tuto-rial); http://sourceforge.net/project/showfiles.php?group_id=171400 (down-load). Data da pesquisa: 04/08/2008.
Ponto de vista: Voltado para teste de software web, onde estes testes sao realizadosjuntamente com a linguagem Java, aumentando assim a seguranca e confiabilidade dostestes realizados.
2.6.17 JUnit
Finalidade: O JUnit e um framework para a plataforma Java que possibilita a criacaode classes de teste unitario. Ele e bastante difundido, tanto que possui integracao comvarias IDEs da plataforma acima mencionada. Alem disso, ele e opensource e permite aautomatizacao dos testes com apresentacao de resultados. E orientado por casos de uso.
Outras informacoes podem ser encontradas nos seguintes sites: http:
//sourceforge.net/projects/junit/; http://www.riehle.org/wpcontent/
uploads/2008/04/sen-2008-03-junit-doc.pdf (tutorial); http://sourceforge.
net/project/showfiles.php?group_id=15278\&package_id=12472 (download). Datada pesquisa: 29/07/2008.
27
2.6. Ferramentas dct-ufms
Ponto de vista: E mundialmente conhecimento na area de desenvolvimento de soft-ware, pois automatiza os testes unitarios com grande eficiencia, alem de ser orientado porcasos de uso. Versao atual: 4.4.
2.6.18 Marathon
Finalidade: O Marathon foi projetado e desenvolvido para ser a mais flexıvel ferramentaJava GUI Testing. Utilizando Jython como framework base, o usuario tem a opcao deinspecionar e agir em quase qualquer aspecto da aplicacao Java sob o teste, pois possuiuso simples de elementos que facilitam acessar os componentes disponıveis na tela. Alemdisso, essa ferramenta utiliza o controle das estruturas e declaracoes condicionais prestadaspelo Jython para automatizar todas e quaisquer acoes da sua aplicacao Java, por exemplo,gravacao, leitura e edicao.
Alem disso, a ferramenta Marathon e utilizada principalmente para a automacao detestes funcionais (testes aplicados ao usuario final ou cliente). E concebıvel que o Marathonpossa ser usado para desenvolver testes antes mesmo de um aplicativo estar disponıvel.
Outras informacoes podem ser encontradas nos seguintes sites: http://www.
marathontesting.com/Home.html; http://www.marathontesting.com/Marathon
(tutorial); http://sourceforge.net/project/showfiles.php?group_id=46616\
&package_id=54685\&release_id=607325 (download). Data da pesquisa: 29/07/2008.
Ponto de vista: Documentacao vasta para facilitar o uso e assim adquirir fundamen-tos para executar e utilizar a ferramenta. Framework Jython base da ferramenta, poucoutilizado. Versao atual: 1.2.0.
2.6.19 METRICS
Finalidade: O METRICS e uma ferramenta que fornece ao usuario diversas informacoesquantitativas sobre o teste, por exemplo, a complexidade e a quantidade de defeitos dosoftware, normalmente indicativos da qualidade de um produto de software.
Outras informacoes podem ser encontradas nos seguintes sites: http://metrics.
sourceforge.net/; http://metrics.sourceforge.net/ (tutorial); http://metrics.
sourceforge.net/ (download). Data da pesquisa: 13/08/2008.
Ponto de vista: A ferramenta fornece muitos benefıcios pois indica onde a engenhariade software deve concentrar seus esforcos de forma a redefinir partes do software e/ouconduzir testes de forma a obter melhores resultados. Versao atual: 1.3.6.
28
2.6. Ferramentas dct-ufms
2.6.20 QTUNIT
Finalidade: A ferramenta QTUNIT realiza testes unitario para C++, compila os dadosem uma biblioteca chamada QT, construıda para atender qualquer plataforma. Os testespodem ser compilados em modulos que sao recarregados automaticamente apos a modi-ficacao. A documentacao gerada (exibicao de onde ocorreram falhas ) pelo teste e de facilacesso. Possui integracao com varias IDE’s de desenvolvimento.
Outras informacoes podem ser encontradas nos seguintes sites: http://www.uwyn.com/projects/qtunit/; http://www.uwyn.com/projects/qtunit/ (tutorial); http:
//www.uwyn.com/projects/qtunit/download.html (download). Data da pesquisa:21/07/2008.
Ponto de vista: Segundo profissionais que utilizam a ferramenta, ela possui docu-mentacao que atende as necessidades dos usuarios da ferramenta . Versao atual: 0.9.8.
2.6.21 SELENIUM
Finalidade: O SELENIUM e uma ferramenta para testar aplicacoes na web por meio dobrowser de forma automatizada. O SELENIUM se refere ao teste funcional que envolveexecutar testes em um sistema finalizado. Os testes executam diretamente em um browser,exatamente como o usuario faria. Alem disso, pode ser integrado ao JUNIT.
Dois componentes sao importantes para gerar e executar testes com SELENIUM:Selenium RC e Selenium IDE. O Selenium RC e um servidor escrito em Java. Ele recebechamadas http e executa os testes. As chamadas vem dos testes unitarios (com JUnit,por exemplo). O Selenium IDE e uma extensao do firefox. A ferramenta auxilia a criacaode casos de testes, pois grava as acoes do usuario, as acoes podem ser transformadas emcodigo em varias linguagens, entre elas java.
Outras informacoes podem ser encontradas nos seguintes sites: http:
//selenium.openqa.org/; http://fernandobichara.blogspot.com/2007/09/
testes-funcionais-na-web-selenium.html (tutorial). Data da pesquisa: 28/07/2008.
Ponto de vista: A caracterıstica principal e poder ser executada em qualquer sistemaoperacional. A ferramenta executa diretamente no browser (por exemplo, firefox). Tambemrealiza teste funcional das propriedades funcionais do sistema. Versao atual: 1.0b2.
2.6.22 Utex (Unit Test Expert for Delphi)
Finalidade: O Utex e uma ferramenta de teste especializada no Delphi que pode serbaixada utilizando um subversion. A meta desse software e a facilidade de aplicacao deteste para programas escritos para Delphi. E opensource.
29
2.6. Ferramentas dct-ufms
Outras informacoes podem ser encontradas nos seguintes sites: http://utex.
tigris.org/; http://utex.tigris.org/servlets/ProjectDocumentList?folderID=
2689 (download). Data da pesquisa: 29/07/2008.
Ponto de vista: E um opensource escrito para uma linguagem em desuso. Versaoatual: 1.2 (versao estavel) e 2.0 (versao em desenvolvimento).
2.6.23 XmlMessageTest
Finalidade: Essa ferramenta e opensource e foi escrita utilizando a linguagem Java. Epossıvel ser executada em qualquer plataforma que suporta Java, e com isso pode serfacilmente integrado. O software serve para facilitar os testes em mensagens baseadas emXML, ou seja, pode-se mandar mensagens escritas em XML sem que tenha que ser escritotodo o codigo necessario para os protocolos de comunicacoes e verificacao de respostas.
Outras informacoes podem ser encontradas nos seguintes sites: http:
//xmlmessagetest.tigris.org/; http://xmlmessagetest.tigris.org/source/
browse/xmlmessagetest/ (download). Data da pesquisa: 29/07/2008.
Ponto de vista: Open source que auxilia o teste de procedimentos de mensagensxml. Requer JDK 1.4 ou mais avancado. Versao atual: 1.1.
A Tabela 2.1 resume os resultados do levantamento realizado.
30
2.6. Ferramentas dct-ufms
Tabela 2.1: Tabela de ferramentasFerramenta Funcionalidade Linguagem
testada pelaferramenta
Empresa de-senvolvedora
Plataforma
Apodora Ferramenta para au-tomatizar testes fun-cionais de aplicacoesweb
C , C++,HTML, ASP,C#, Perl,Javascript,PHP, ASP.net,JSP, VB.net
ACULIS Microsoft Win-dows NT,Windows 2000,Windows XP,Windows Server2003
Check Teste unitario para lin-guagem C
C Software livre POSIX (Linux,BSD, UNIX-likeOSes)
ContinuousTesting forEclipse
Executa teste unitarioem conjunto com aIDE Eclipse
Java Software livre Multiplataforma
csUnit Teste unitario C#, VB .NET,Visual Java ouDirigido C++.
Software livre Microsoft Win-dows XP SP2 ou WindowsVista SP 1
Cut Teste unitario C, C++, Objec-tive C
Software livre Multiplataforma
CuTest Teste unitario C Software livre MultiplataformaDave’s UnitTest (DUT)
Teste unitario (validacondicoes booleanos)
C, C++ Software livre Linux
DBFeeder Testa banco de dados Oracle Software livre MultiplataformaDejaGnu Prove interface simples
para escrever os testespara diversos progra-mas
Tcl, C,C++, Javae aplicacoes derede
Rob Savoye, eBen Elliston
MacOS, Mi-crosoft Win-dows, POSIXMacOS, POSIX
Eclemma Cobertura de testeunitario
Java Software livre IDE Eclipse
IBM Ratio-nal FunctionalTester 7.0
Teste funcional .Net, Java,HTML, Siebel,SAP, AJAX eFlex
IBM Microsoft Win-dows 2000,Windows XP,Windows Vistae Linux
ISPIS Fornece um processode inspecao de software
Multi linguagem Grupo de En-genharia deSoftware Ex-perimentalCOPPE/UFRJ
Multiplataforma
Javatt Teste de caixa preta ebranca (Testa cenarioa partir de arquivosXML)
Java MatthiasKempa
Multiplataforma
31
2.6. Ferramentas dct-ufms
Ferramenta Funcionalidade Linguagemtestada pelaferramenta
Empresa de-senvolvedora
Plataforma
Jemmy Teste unitario para in-terfaces swing
Java NetBeans Multiplataforma
Jf-unittest Teste unitario C++ Software livre LinuxJsTester Validacao de codigo
JavaScriptJava Software livre Multiplataforma
JUnit Teste unitario Java Software livre MultiplataformaMarathon 1.2.0 Automacao de testes
funcionaisJava Jalian Systems
Private LtdMicrosoft Win-dows e Linux
Metrics Extracao de diferentesmetricas do codigo aser testado
Java Software livre Multiplataforma
QtUnit Teste unitario C++ Software livre MultiplataformaSelenium Teste funcional no
browserFerramenta web Software livre Multiplataforma
Utex Teste unitario Delphi Software livre MicrosoftWindows
XmlMessage-Test
Teste unitario XML Software livre Multiplataforma
32
Capıtulo 3
Estudo pratico
Apos a realizacao do estudo descrito nas secoes anteriores, buscou-se utilizar o conheci-mento adquirido para realizar um estudo pratico em teste de software considerando umaaplicacao real desenvolvida por uma empresa de software.
Antes de executar os testes e obter os resultados, foi construıdo um plano de teste parateste unitario, onde a intencao e orientar como devem realizados os testes unitarios paradeterminado codigo implementado. Antes de elaborar os casos de teste e executa-los naaplicacao real considerada neste trabalho, foi identificado um processo para teste unitario(secao 3.1), e foi realizado um estudo pratico piloto (secao 3.2) sugerido na literatura.
3.1 Processo de teste unitario
O teste unitario consiste em realizar testes especıficos em metodos de forma a verificar evalidar a corretude desses para o software em desenvolvimento (Pressman, 2007).
A intencao e varrer um conjunto de metodos a fim de encontrar falhas ou erros. Tendoem maos o processo de teste, inicia-se o projeto dos casos de testes, onde serao moldadosos cenarios basicos para realizacao do teste unitario.
O plano de caso de teste construıdo focaliza-se em abordar testes unitarios. Logo,foram escolhidas ferramentas que realizavam esses tipos de teste e que dariam suporte aexecucao e a realizacao dos testes. A partir deste enfoque, as ferramentas selecionadas parafazer parte do processo pratico de teste unitario foram: Metrics, JUnit e Eclemma, que,quando integradas, contribuem para analises e validacoes especıficas para determinadasetapas do processo de teste e como resultado, um processo de teste unitario automati-zado integrando ferramentas com o intuito de promover a execucao desta implementacao,atividade de garantia de qualidade de software.
33
3.1. Processo de teste unitario dct-ufms
3.1.1 Processo para realizacao de teste unitario
O objetivo do processo de teste e realizar uma analise para planejar e executar os casosde testes. Os passos identificados a seguir compoem o processo de teste unitario.
1. Para cada metodo da classe a ser testada, construir o grafo de fluxo;
2. A partir do grafo, calcular a complexidade ciclomatica. Caso julgue necessario, uti-lizar outras medidas, entre elas:
• Numero de linhas dos metodos de uma classe (avaliar o tempo que sera gastopara testar metodos);
• Dependencias entre metodos e classes (obter uma situacao em relacao a quan-tidade das dependencias dos metodos a serem testados, tais como, um metodoque depende de metodos de outras classes);
3. Partindo das informacoes obtidas anteriormente, gerar os casos de teste, avaliando:
• Recebimento de parametros dos metodos;
• Parametros (conforme as regras de negocios);
• Valores limites;
• Cada fluxo do metodo;
4. Executar os testes;
5. Documentar os resultados obtidos durante a realizacao dos casos de teste;
3.1.2 Casos de teste utilizando ferramentas
Neste trabalho, todos os casos de testes foram projetados para testar codigos na linguagemJava, pois esta e uma linguagem muito conhecida e predominante no mercado atual, comopode ser visto na Figura 3.1. Para que os testes sejam realizados na pratica, pode-seutilizar algumas ferramentas que automatizam o teste unitario, entre elas Metrics, JUnit,Eclemma e Ant, juntamente com a IDE Eclipse. Apresenta-se, a seguir, uma sugestaode execucao do processo de teste unitario e o uso de ferramentas, note que o uso dasferramentas nao e obrigatorio e sim complementar.
Passos para realizacao de teste unitario
1. Utilizar a ferramenta Metrics para analisar e verificar medidas das classes a seremtestadas. Algumas das metricas fornecidas pela ferramenta sao:
• Complexidade ciclomatica;
• Quantidade de parametros;
34
3.1. Processo de teste unitario dct-ufms
Figura 3.1: Desmonstrando a importancia da linguagem Java (Tiobe).
• Numero de subclasses;
• Numeros de linhas de codigo total;
• Outros que julgar necessario.
2. Com o uso de um editor de textos, e considerando o valor da complexidade ci-clomatica, construir casos de testes com base na analise realizada no passo anteriora fim de varrer os metodos da classe a ser testada. Caso julgue necessario, acrescenteo uso de outras metricas.
3. Com o plano de testes em maos, pode-se comecar a implementacao dos casos de testeutilizando o JUnit, testando e corrigindo os problemas encontrados. Continua-seneste passo enquanto nao forem cobertos todos os casos de teste ou houver problemasa serem corrigidos;
4. Com a ferramenta Eclemma, obter uma analise da cobertura do testes por linhas,caso nao tenha coberto corretamente a classe testada, verificar quais testes nao foramaplicados corretamente e voltar ao passo 2. Se nao foi possıvel finalizar o processode teste, passar ao proximo passo;
5. Gerar documentacao com os resultados obtidos a partir dos testes realizados, repor-tando os erros e acertos encontrados. Neste caso foi utilizada a ferramenta Ant, que eutilizada para gerenciar a realizacao da compilacao de codigos java, gerar relatorios,gerar documentacao do projeto, entre outras atividades, de forma automatizada.Ela foi utilizada neste processo coletando os dados gerados pelo JUnit e fornecendoum relatorio em formato Html.
35
3.1. Processo de teste unitario dct-ufms
Portanto, o objetivo da integracao das ferramentas e conseguir resultados praticos quemostrem as vantagens que os testes unitarios trazem quando utilizados no desenvolvimentode software. As ferramentas mencionadas nesta secao sao descritas em detalhes nas secoesseguintes.
3.1.3 Metrics
Esta ferramenta e fornecida exclusivamente para uso em conjunto com IDE Eclipse emforma de plugin, e e uma ferramenta livre, de facil instalacao e utilizacao.
Algumas das metricas e funcionalidades da ferramenta sao listadas a seguir:
• Indica a complexidade ciclomatica;
• Proporciona uma medida quantitativa da complexidade logica de um algoritmo, ouseja, apresenta o numero de caminhos possıveis de um algoritmo por meio do seunumero de condicoes (if, for, while, do e switch);
• Apresenta o numero de parametros;
• Indica o numero total de parametros no escopo selecionado;
• Apresenta a profundidade da arvore de heranca;
Para ilustrar a utilizacao da ferramenta, segue um codigo que fornece a cor para umcarro, conforme algumas caracterısticas:
1 public class Carro{23 public String corCarro(Integer tipoCarro){45 if(tipoCarro == 0){6 return "Amarelo";7 }else{8 return "Azul";9 }
10 }11 }
A utilizacao da ferramenta Metrcis para avaliar o metodo corCarro da classe Carro,nos fornece algumas medidas, como pode ser observado na Figura 3.2:
O suporte oferecido ao usuario da ferramenta fornece instrumentos para que haja umaanalise completa no metodo ou classe em questao. A ferramenta permite ao desenvolvedorrefletir sobre modificacoes no software baseadas nos valores das metricas que estao ou naodentro de intervalos pre-definidos, ou ainda configuradas de acordo com a sua necessidade.
36
3.1. Processo de teste unitario dct-ufms
Figura 3.2: Resultado da analise com a ferramenta Metrics para o metodo corCarro.
3.1.4 JUnit
O JUnit e um framework desenvolvido para a linguagem Java que permite a criacao eautomacao de testes unitarios. Ele e integrado com as principais IDEs Java e conta comuma grande comunidade de usuarios, principalmente desenvolvedores de codigo-aberto,ou seja, tem uma otima aceitacao e e muito utilizado.
Este software facilita a construcao de testes unitarios e, com isso, contribui paraeliminar varios erros que existem no codigo. Com isso, a fase de teste se torna maisagradavel e menos trabalhosa. Normalmente, a ferramenta JUnit e utilizada da seguinteforma: primeiramente, e configurado a IDE java que sera utilizada, lembrando que o JUnitja vem inserido nos principais IDEs, mas pode ser que seja necessario instala-lo. Emseguida, abre-se o codigo fonte java e instancia-se o JUnit para o projeto. A partir destemomento, pode-se criar uma classe de teste em que deve-se exercitar todas as propriedadesde um teste unitario. A seguir um exemplo de classe java:
1 public class Operacao2 {3 public integer soma(Integer a, Integer b)4 {5 return a+b;6 }7 }
Com este exemplo em maos, pode-se criar um classe de teste com JUnit:
1 import junit.framework.testcase23 public class TestOperacao extends TestCase4 {56 public void testsoma ()7 {8 Operacao intancia = new Operacao ();9 Integer resultado = instancia.soma (5,12);
10 assertEquals(Integer.valueOf (17) , resultado);11 }12 }
37
3.1. Processo de teste unitario dct-ufms
Na primeira linha, a biblioteca necessaria para executar o JUnit esta sendo importada.Na segunda, e definida uma classe de teste para a classe que se deseja testar e estender deTestCase, a qual e uma classe base do framework JUnit. Depois de criar um metodo deteste, instanciar a classe “operacao” e chamar o metodo que pretender testar, que nestecaso e o metodo soma, que retorna o valor calculado e guarda na variavel “resultado”.Na linha 10, e utilizado um metodo especıfico do JUnit, o assertEquals, que compara oresultado da variavel com o valor correto que deveria ser retornado.
O JUnit disponibiliza em um display os acertos, erros e falhas, onde o acerto seriaquando o metodo assertEquals compara os dois valores passados como parametro e essesvalores sao iguais, logo aparece no display como um item verde. O erro e mostrado quandoexiste um metodo chamado no parametro da assertEquals e este metodo nao consegueexecutar, assim, nao retorna valor algum para o parametro do assertEquals, e no displayaparecera um X vermelho. Ja a falha acontece quando os dois parametros do assertEqualssao diferentes e no display aparece um X azul. A Figura 3.3 detalha melhor como edisponibilizado os acertos, erros e falhas.
Figura 3.3: Display da ferramenta JUnit
As principais vantagens de se utilizar este framework sao:
1. Permitir a criacao rapida de testes unitarios, melhorando a qualidade do desenvolvi-mento.
2. Contem muitos desenvolvedores de codigo aberto e como estes se comunicam emforuns, acabam por oferecer muitos exemplos praticos.
3. Depois de serem escritos, os testes sao executados rapidamente e quantas vezesforem necessarias, sem que o processo de desenvolvimento seja interrompido.
4. O JUnit e gratuito e orientado a objetos. Ele pode testar cada metodo de umaclasse.
38
3.1. Processo de teste unitario dct-ufms
3.1.5 Eclemma
Eclemma e uma ferramenta gratuita desenvolvida para fazer teste de cobertura em codigode Java. Ela e de facil instalacao e seu unico empecilho e o fato de ela ser usada somentena IDE Eclipse.
Essa ferramenta e util durante todo processo de codificacao que utiliza o JUnit, poisela apresenta informacoes como a classe, o percentual de cobertura, as instrucoes cobertase o total de instrucoes cobertas, conforme pode ser visto na Figura 3.4.
Figura 3.4: Display da ferramenta Eclemma
Assim, ao desenvolver os casos de teste com o JUnit, pode-se executar em conjuntoa ferramenta Eclemma e, com isso, analisar em quanto a classe de teste esta cobrindo ocodigo em questao, ou seja, o quanto o teste esta sendo bem feito.
Se for utilizado o Eclemma na classe carro apresentada anteriormente e executada emconjunto com o JUnit, a ferramenta retorna a quantidade de linhas cobertas do codigo etambem apresenta as linhas por onde foi executado codigo de cores diferentes. Onde a linhaestiver verde, significa que a linha foi executada, onde a linha estiver amarela, significaque a linha foi parcialmente executada e onde a linha estiver vermelha, significa que alinha nao foi executada. A figura 3.5 mostra o codigo da classe carro com as propriedadesdescritas anteriormente.
Figura 3.5: Codigo da classe carro com as linhas coloridas conforme descrito anteriormente
As funcionalidades citadas acima representam o funciomaneto basico da ferramenta,e com esse conhecimento ja se pode fazer uma analise mais detalhada do que esta sendorealmente testado e se o teste esta sendo bem implementado. Com esses dados em maos,
39
3.2. Primeiro Caso Pratico dct-ufms
e possıvel melhorar a qualidade do teste e consequentemente a qualidade do software queesta sendo contruıdo.
Apos a identificacao do processo de teste unitario e o estudo das ferramentas quecontribuem para a execucao do teste, foi realizado um estudo piloto com o intuito deaplicar os conhecimentos obtidos conforme apresentado na secao 3.2.
3.2 Primeiro Caso Pratico
Para fazer um estudo de caso de teste unitario em aplicacoes Java foi utilizada a ClasseAluno(Araujo, 2008), descrita a seguir, que calcula aprovacao do aluno conforme mediade notas e frequencia.
Plano de caso de teste unitario para a classe Aluno.
1 public class Aluno {2 private Integer frequencia;3 private Float nota1;4 private Float nota2;5 private Float notaFinal;67 public Integer getFrequencia () {8 return frequencia;9 }
10 public void setFrequencia(Integer frequencia) {11 this.frequencia = frequencia;12 }13 public Float getNota1 () {14 return nota1;15 }16 public void setNota1(Float nota1) {17 this.nota1 = nota1;18 }19 public Float getNota2 () {20 return nota2;21 }22 public void setNota2(Float nota2) {23 this.nota2 = nota2;24 }25 public Float getNotaFinal () {26 return notaFinal;27 }2829 public void setNotaFinal(Float notaFinal) {30 this.notaFinal = notaFinal;31 }32 public Boolean calcularAprovacao () {
40
3.2. Primeiro Caso Pratico dct-ufms
3334 if (frequencia < 75) {35 return Boolean.FALSE;36 } else {37 float media;38 float mediaFinal;39 media = (nota1 + nota2)/2;4041 if (media < 30) {42 return Boolean.FALSE;43 } else {44 if (media >= 70) {45 return Boolean.TRUE;46 } else {47 mediaFinal = (media +
notaFinal) / 2;48 if (mediaFinal >= 50) {49 return Boolean.
TRUE;50 } else {51 return Boolean.
FALSE;52 }53 }54 }55 }56 }57 }
A seguir descreve-se como foram realizadas as 5 etapas de teste para a classe aluno,utilizando o editor Eclipse, com as ferramentas Metrics, JUnit, Eclemma e Ant.
1. METRICS: Por meio desta ferramenta, analisam-se os metodos da classe
Metodo: calcularAprovacao obtem-se as seguintes medidas:
• Complexidade ciclomatica: 5;
• Numero de parametros: nenhum;
• Numero de linhas: 24;
• Dependencias de metodos de outras classes: nenhum;
• Dependencias de outros metodos: nao.
** Os outros metodos foram desconsiderados pois sao getters e setters triviais, enao precisam ser testados.
A analise realizada mostra que os metodos da classe ‘Aluno’ exigem 5 casos de testedevido a complexidade ciclomatica.
41
3.2. Primeiro Caso Pratico dct-ufms
2. Construir casos de teste
• Com base na complexidade ciclomatica:
2.1 - situacao reprovado por frequencia = 74— metodo deve retornar valor boolean false.
2.2 – situacao frequencia = 75 e reprovado por nota, onde nota1 = 29 e nota2= 30, ou seja, media = 29,5 logo media < 30.
— metodo deve retornar valor boolean false.
2.3 - situacao frequencia = 75 e aprovado por nota, onde nota1 = 70 e nota2= 70, ou seja, media = 70 logo media >=70.
— metodo deve retornar valor boolean true.
2.4 - situacao frequencia = 75 e aprovado por notaFinal, onde nota1 = 30,nota2 = 30, ou seja media = 30, notaFinal = 70, media + notaFinal = 50logo media >= 30 e mediaFinal >=50.
— metodo deve retornar valor boolean true.
2.5 - situacao frequencia = 75 e reprovado por notaFinal, onde nota1 = 30 enota2 = 30, ou seja media = 30, notaFinal = 69, media + notaFinal = 49,5logo media >= 30 e mediaFinal < 50.
— metodo deve retornar valor boolean false.
• Com base no valor limite dos atributos:
2.6 - testar valores 74, 75 e 76 para o atributo frequencia.— valores 74 e 75 ja foram testados nos casos 1 e 2 respectivamente.
2.6.1 - situacao frequencia = 76 e reprovada por nota, onde nota1 = 29 enota2 = 30, ou seja, media = 29,5 logo media < 30.
— metodo deve retornar valor boolean false.
2.7 - testar valores 29,5, 30 e 30,5 para o atributo media.— valores 29,5 e 30 ja foram testados nos casos 2 e 4 respectivamente.
2.7.1 - situacao frequencia = 75 e aprovado por nota, onde nota1 = 31, nota2= 30, media = 30,5 e notaFinal = 70 ou seja, media >= 30 e media +notaFinal = 50,25 logo mediaFinal > 50.
— metodo deve retornar valor boolean true.
2.8 - testar valores 69,5, 70 e 70,5 para o atributo media.— valor 70 ja foi testado no caso 3.
2.8.1 - situacao frequencia = 75 e aprovado por notaFinal, onde nota1= 69,nota2 = 70, media = 69,5 e notaFinal = 50, ou seja, media < 70 e media +
42
3.2. Primeiro Caso Pratico dct-ufms
notaFinal = 59,75 logo mediaFinal > 50.— metodo deve retornar valor boolean true.
2.8.2 - situacao frequencia = 75 e aprovado por nota, onde nota1 = 70, nota2= 71 e media = 70,5, ou seja, media >= 70.
— metodo deve retornar valor boolean true.
2.9 - testar valores 49,5, 50 e 50,5 para o atributo notaFinal— valores 49,5, 50 e 50,5 ja foram testados nos casos 2.4, 2.5 e 2.7.1
respectivamente.
3. JUnit: Executar casos de teste3.1 - Implementar os casos de testes acima, conforme sugerido por Araujo (2008) eadaptado pelos autores deste projeto.
1 import junit.framework.TestCase;2 import br.com.estudo.jUnit.aluno.Aluno;3 /**
4 * Classe responsavel pela implementacao dos casos de teste
5 * para testar o metodo calcularAprovacao da classe Aluno.
6 */
7 public class TestAluno extends TestCase {89 // Atributo da classe Aluno.java.
10 private Aluno aluno;1112 /*
13 * Metodo executado toda vez que um
14 * metodo de caso de teste e executado.
15 */
16 protected void setUp () throws Exception{17 super.setUp ();18 aluno = new Aluno ();19 }2021 /*
22 * Construcao dos casos de teste a partir
23 * da complexidade ciclomatica.
24 */
2526 // Caso de teste 2.1
27 public voidtestCalcularAprovacao_ReprovacaoPorFrequencia (){
28 aluno.setFrequencia (74);29 assertEquals(Boolean.FALSE , aluno.
calcularAprovacao ());30 }31
43
3.2. Primeiro Caso Pratico dct-ufms
32 // Caso de teste 2.2
33 public voidtestCalcularAprovacao_ReprovacaoPorNotas12 (){
34 aluno.setFrequencia (75);35 aluno.setNota1 (29);36 aluno.setNota2 (30);37 assertEquals(Boolean.FALSE ,aluno.
calcularAprovacao ());38 }3940 // Caso de teste 2.3
41 public void testCalcularAprovacao_AprovacaoPorNotas12(){
42 aluno.setFrequencia (75);43 aluno.setNota1 (70);44 aluno.setNota2 (70);45 assertEquals(Boolean.TRUE , aluno.
calcularAprovacao ());46 }4748 // Caso de teste 2.4
49 public voidtestCalcularAprovacao_AprovacaoPorNotaFinal (){
50 aluno.setFrequencia (75);51 aluno.setNota1 (30);52 aluno.setNota2 (30);53 aluno.setNotaFinal (70);54 assertEquals(Boolean.TRUE , aluno.
calcularAprovacao ());55 }5657 // Caso de teste 2.5
58 public voidtestCalcularAprovacao_ReprovacaoPorNotaFinal (){
59 aluno.setFrequencia (75);60 aluno.setNota1 (30);61 aluno.setNota2 (30);62 aluno.setNotaFinal (69);63 assertEquals(Boolean.FALSE , aluno.
calcularAprovacao ());64 }6566 /*
67 * Implementacao dos casos de teste para
68 * analisar valores limites dos atributos
69 * utilizados no metodo calcularAprovacao.
70 */
7172 // Caso de teste 2.6.1
44
3.2. Primeiro Caso Pratico dct-ufms
73 public void testCalcularAprovacao_ReprovacaoPorNotas_VerificarFrequencia76 (){
74 aluno.setFrequencia (76);75 aluno.setNota1 (29);76 aluno.setNota2 (30);77 assertEquals(Boolean.FALSE ,aluno.
calcularAprovacao ());78 }7980 // Caso de teste 2.7.1
81 public voidtestCalcularAprovacao_AprovacaoPorNotaFinal_VerificarNotas305 (){
82 aluno.setFrequencia (75);83 aluno.setNota1 (31);84 aluno.setNota2 (30);85 aluno.setNotaFinal (70);86 assertEquals(Boolean.TRUE ,aluno.
calcularAprovacao ());87 }8889 // Caso de teste 2.8.1
90 public voidtestCalcularAprovacao_AprovacaoPorNotaFinal_VerificarNotas695 (){
91 aluno.setFrequencia (75);92 aluno.setNota1 (69);93 aluno.setNota2 (70);94 aluno.setNotaFinal (50);95 assertEquals(Boolean.TRUE , aluno.
calcularAprovacao ());96 }9798 // Caso de teste 2.8.2
99 public void testCalcularAprovacao_AprovacaoPorNotas_VerificarNotas705 (){
100 aluno.setFrequencia (75);101 aluno.setNota1 (70);102 aluno.setNota2 (71);103 assertEquals(Boolean.TRUE , aluno.
calcularAprovacao ());104 }105106 } // fim classe.
3.2 - Execucao dos casos de teste implementados no item anterior.
4. Eclemma: Analisar resultados
45
3.2. Primeiro Caso Pratico dct-ufms
4.1 - Metodo: calcularAprovacao obteve as seguintes analises.
- obteve 100% de cobertura das linhas, conforme pode ser observado naFigura 3.1.
Figura 3.6: Figura exemplificando o resultado da execucao do Eclemma, alcancando 100%de cobertura das linhas
4.2 - Como o metodo em questao foi todo coberto, deve-se passar para o proximopasso.
5. Documentacao: Gerar relatorio
5.1 - Nao foram encontrados erros ou falhas na execucao dos casos de teste, comopode ser visto nas Figuras 3.2 e 3.3.
5.2 - Codigo 100% correto.
5.3 - Plano de casos de teste homologado.
46
3.2. Primeiro Caso Pratico dct-ufms
Figura 3.7: Figura exemplificando modelo de relatorio gerado pelo caso de teste aluno,utilizou-se o Ant
Figura 3.8: Figura exemplificando modelo de relatorio gerado pelo caso de teste aluno,utilizou-se o Ant
47
3.3. Segundo Caso Pratico dct-ufms
3.3 Segundo Caso Pratico
O segundo estudo de caso pratico teve como objetivo principal unir e exercitar testesunitarios, aproximando-se o maximo possıvel de um software do mundo real. As imple-mentacoes de casos de teste e execucao de testes unitarios foram realizadas em parce-ria com uma empresa da cidade de Campo Grande, Desenvolvimento de Sistemas Fis-cais (DSF). Com a parceria entre universidade e empresa, pode-se observar que houveum ganho significativo para ambas as partes, pois a empresa ofereceu espaco para quepudessem ser realizados testes em softwares que vem sendo desenvolvidos atualmente, epor outro lado, a universidade contribuiu com a pesquisa e aplicacao de um processo deteste unitario para oferecer maior qualidade ao software desenvolvido pela empresa.
O fato da empresa proporcionar o exercıcio de atividades de testes em um softwarereal contribuiu para alavancar ainda mais este projeto. O sistema que foi utilizado pararealizacao de testes unitarios atualmente esta em processo de construcao, esta sendo im-plementado na linguagem Java e estara disponıvel para uso via Internet.
A DSF esta posicionada hoje como uma das principais empresas de Gestao TributariaMunicipal. Desde 1994, a empresa tem como missao fornecer solucoes que possibilitemao governo municipal uma gestao fiscal responsavel, aliando colaboradores motivados,tecnologia e conhecimento para que o municıpio possa cumprir sua funcao social. O Sis-tema Integrado de Administracao Tributario (SIAT) em desenvolvimento atualmente econsiderado uma moderna solucao que objetiva administrar o lancamento, o registro e acobranca de todos os tributos municipais, contem-plando uma visao global e integrada daadministracao tributaria municipal. O sistema tem a finalidade de gerenciar e controlar oscadastros de imoveis e de atividades economicas que servem de base para o lancamento detributos, bem como a avaliacao, lancamento, arrecadacao e fiscalizacao dos mesmos, prop-iciando o lancamento e o controle da arrecadacao dos tributos municipais: IPTU, ITBI eISS, alem das taxas a eles associadas, com total seguranca nas informacoes, permitindoacoes concretas no gerenciamento municipal e um planejamento eficaz das acoes do fisco.
A partir daı, foi escolhido um caso de uso pelo responsavel da empresa para a realizacaodos testes. Ele forneceu toda a documentacao para que fosse possıvel planejar e executaros testes necessarios para verificar e validar a corretude das regras de negocio contidasno caso de uso Manter Distrito. Este caso de uso e responsavel pela manutencao daentidade Distrito. O objetivo desta entidade e delimitar espacialmente a cidade parafins cartograficos, ou seja, a cidade e dividida em regioes e sub-regioes para poder serrepresentada em mapas cartograficos.
Houve inicialmente a construcao do plano de teste unitario, onde estava contida todaa documentacao e passos necessarios para a realizacao dos testes unitarios utilizando asferramentas Metrics, JUnit, Eclemma e Ant.
A seguir, e apresentado o plano de teste construıdo para o caso de uso fornecido pelaempresa DSF, Manter Distrito. O codigo fonte do “Manter Distrito” nao foi documentadopor ser uma documentacao sigilosa.
48
3.3. Segundo Caso Pratico dct-ufms
Plano de caso de teste unitario para caso de uso ‘Manter Distrito’.
Para algumas regras de negocio do caso de uso nao foram criados casos de teste, poisa forma como foram implementadas nao possibilitariam a execucao dos casos de testesusando JUnit (os metodos nao tinham nenhum valor de retorno, logo nao era possıvelutilizar o metodo de assert para avaliar o valor de retorno). Por isso, foi enviado umdocumento a empresa reportando os testes que nao puderam ser realizados. Os metodosque nao puderam ser testadas sao:
• Distrito com a mesma inscricao;
• Distrito invalido;
• Zona fiscal invalida.
1. METRICS : Por meio desta ferramenta, analisam-se os metodos da classe
Metodo: acaoEspecifica obteve as seguintes medidas:
• Complexidade ciclomatica: 2;
• Numero de parametros: 1;
• Numero de linhas: 4;
• Dependencias de metodos de outras classes: nenhum;
• Dependencias de outros metodos: nao.
Metodo: antesDesativar obteve as seguintes medidas:
• Complexidade ciclomatica: 3;
• Numero de parametros: 2;
• Numero de linhas: 8;
• Dependencias de metodos de outras classes: nenhum;
• Dependencias de outros metodos: nao.
Metodo: validadatareferencia obteve as seguintes medidas:
• Complexidade ciclomatica: 3;
• Numero de parametros: 1;
• Numero de linhas: 6;
• Dependencias de metodos de outras classes: nenhum;
• Dependencias de outros metodos: nao.
Metodo: validaDistritoPodeSerAlterado obteve as seguintes medidas:
• Complexidade ciclomatica: 2;
• Numero de parametros: 1;
49
3.3. Segundo Caso Pratico dct-ufms
• Numero de linhas: 4;
• Dependencias de metodos de outras classes: nenhum;
• Dependencias de outros metodos: nao.
Metodo: restricaoInclusaoAlteracao obteve as seguintes medidas:
• Complexidade ciclomatica: 3;
• Numero de parametros: 2;
• Numero de linhas: 9;
• Dependencias de metodos de outras classes: nenhum;
• Dependencias de outros metodos: sim, validadatareferencia e validaDistri-toPodeSerAlterado.
2. Construir casos de teste para cada Metodo
Casos de teste cenario ‘acaoEspecifica’.
• Com base na complexidade ciclomatica:
2.1 - situacao em que atributo ativo do distrito nao e ativo, ou seja, distri-toVO.ativo recebe Boleano.N.
— metodo deve retornar valor Boleano.S.
2.2 - situacao em que atributo ativo do distrito e nulo, ou seja, distritoVOrecebe null.
— metodo deve retornar valor null.
• Com base nos valores dos parametros:
2.3 - situacao em que atributo ativo do distrito esta ativo, ou seja, distri-toVO.ativo recebe null.
— metodo deve retornar valor null.
2.4 - situacao em que atributo ativo do distrito ja e ativo, ou seja, distri-toVO.ativo recebe Boleano.S.
— metodo de retornar Boleano.S.
• Com base no valor limite dos atributos:
— testar valores Boleano.S, Boleano.N e null para o atributo ativo.— valores Boleano.S, Boleano.N e null ja foram testados nos casos 2.4,
2.1 e 2.2 respectivamente.
Casos de teste cenario ‘antesDesativar’.
• Com Base na complexidade ciclomatica:
50
3.3. Segundo Caso Pratico dct-ufms
2.5 - situacao em que atributo ativo do distrito esta ativo, ou seja, distri-toVO.ativo recebe Boleano.S.
— metodo deve retornar Bolenao.N.
2.6 - situacao em que atributo ativo do distrito ja estava desativado, ou seja,distritoVO.ativo recebe Boleano.N.
— metodo deve retornar Boleano.N.
2.7 - situacao que tem face de Quadra e atributo ativo do distrito esta ativo,ou seja, distritoVO.ativo recebe Boleano.S e temFaceQuadra recebe Boleano.S.
— metodo deve retornar mensagem “ucsiatimo028.M3”.
• Com base nos valores dos parametros:
2.8 - situacao em que atributo ativo do distrito e nulo e face de quadraBoleano.N, ou seja, distritoVO recebe null e temFaceQuadra recebe Boleano.N.
— metodo deve retornar null.
2.9 - situacao em que face de quadra e nulo, ou seja, e temFaceQuadra recebenull.
— metodo deve retornar null.
2.10 - situacao em que atributos ativo do distrito e face de quadra sao nulos,ou seja, e temFaceQuadra recebe null e distritoVO.ativo recebe null.
— metodo deve retornar Boleano.N
• Com base no valor limite dos atributos:
— testar valores Boleano.S, Boleano.N e null para o atributo face dequadra.
— valores Boleano.S, Boleano.N e null ja foram testados nos casos 2.5,2.6 e 2.9 respectivamente.
Casos de teste cenario ‘validadatareferencia’.
• Com Base na complexidade ciclomatica:
2.11 - situacao em que a data referencia e do dia corrente, ou seja, atributodata recebe o valor hoje.
— metodo deve retornar boolean TRUE.
2.12 - situacao em que a data referencia e maior que a data corrente, ou seja,atributo data recebe o valor amanha.
— metodo deve retornar boolean TRUE.
2.13 - situacao em que a data referencia e menor que a data corrente, ou seja,atributo data recebe o valor ontem.
51
3.3. Segundo Caso Pratico dct-ufms
— metodo deve retornar bolean FALSE.
• Com base nos valores dos parametros:
2.14 - situacao em que a data referencia e nulo, ou seja, atributo data recebeo valor null (atributo data recebe o valor amanha).
— metodo deve retornar null.
• Com base no valor limite dos atributos:
— testar valores acima, igual, abaixo e nulo para o atributo data emrelacao a uma data corrente.
— valores acima, igual, abaixo e null ja foram testados nos casos 2.2,2.11, 2.13 e 2.14 respectivamente.
Casos de teste ‘validadistritopodeseralterado’.
• Com Base na complexidade ciclomatica:
2.15 - situacao em que atributo ativo do distrito esta desativado, distri-toVO.ativo recebe Boleano.N.
— metodo deve retornar boolean FALSE.
2.16 - situacao em que atributo ativo do distrito esta ativo, distritoVO.ativorecebe Boleano.S.
— metodo deve retornar boolean TRUE.
• Com base nos valores dos parametros:
2.17 - situacao em que atributo ativo do distrito nulo, distritoVO.ativo recebenull.
— metodo deve retornar boolean null.
• Com base no valor limite dos atributos:
— testar valores Boleano.S, Boleano.N e null para o atributo ativo.— valores Boleano.S, Boleano.N e null ja foram testados nos casos 2.16,
2.15 e 2.17 respectivamente.
Casos de teste cenario ‘restricaoInclusaoAlteracao’
• Com Base na complexidade ciclomatica:
2.18 - situacao em que mensagem e igual a vazia, ou seja, o metodo nao listanenhuma mensagem de erro.
— metodo deve retornar uma lista.
2.19 - situacao em que e exibida a mensagem 4, ou seja, o metodo listamensagem de erro = “ucsiatimo028.M4”.
52
3.3. Segundo Caso Pratico dct-ufms
— metodo deve retornar mensagem 4.
2.20 - situacao em que e exibida a mensagem 5, ou seja, o metodo listamensagem de erro = “ucsiatimo028.M5”.
— metodo deve retornar mensagem 5.
• Com base nos valores dos parametros:
2.21 - situacao em que o metodo retorna duas mensagens, m4 e m5, ou seja, ometodo lista duas mensagem de erros citadas anteriormente.
— metodo deve retornar duas mensagens.
• Com base no valor limite dos atributos:
— como este metodo depende dos metodos validadatareferencia evalidadistritopodeseralterado, e a analise de valor limite ja foram feitas paraesses metodos, nao e preciso fazer novamente.
3. Junit : Executar casos de teste
1 import java.text.ParseException;2 import java.text.SimpleDateFormat;3 import java.util.Calendar;4 import java.util.Collections;5 import java.util.Date;6 import java.util.List;7 import br.com.dsf.bridge.comuns.DsfMensagem;8 import br.com.dsf.bridge.vo.Boleano;9 import br.com.dsf.gtm.bridge.imo.zon.modelo.
DistritoBO;10 import br.com.dsf.gtm.bridge.imo.zon.vo.DistritoVO;11 import com.powerlogic.jcompany.comuns.PlcException;12 import com.powerlogic.jcompanyqa.PlcBaseTestCase;1314 /**
15 *
16 * Realizado teste unitario para validar as
17 * regras de negocio do UCSIATIMO028 - Manter
Distrito
18 *
19 * @author Andre , Davison , Jucimara
20 *
21 */
22 public class DistritoTest extends PlcBaseTestCase {2324 /**
25 * Atributos utilizados para realizacao dos testes
26 */
27 DistritoBO distritoBO = null;
53
3.3. Segundo Caso Pratico dct-ufms
28 DistritoVO distritoVO = null;29 protected static final SimpleDateFormat formatter =
new SimpleDateFormat(‘‘dd/MM/yyyy’’);30 static {31 formatter.setLenient(false);32 }3334 /**
35 * Metodos auxiliares utilizados para realizacao dos
testes
36 * - Metodo 1
37 * - Metodo 2
38 */
3940 // Metodo 1
41 public static Date amanha (Date hoje) {42 Calendar cal = Calendar.getInstance ();43 cal.setTime (hoje);44 cal.add (Calendar.DATE , +1);45 return cal.getTime ();46 }4748 // Metodo 2
49 public static Date ontem (Date hoje) {50 Calendar cal = Calendar.getInstance ();51 cal.setTime (hoje);52 cal.add (Calendar.DATE , -1);53 return cal.getTime ();54 }5556 // Metodo executado toda vez que um metodo de caso de
teste e executado
57 @Override58 protected void setUp () throws Exception {59 super.setUp ();60 this.distritoBO = (DistritoBO)
getBO(DistritoBO.class);61 distritoVO = new DistritoVO ();62 }636465 // - Teste cenario ’acaoEspecifica ’
66 /**
67 * Construcao dos casos de teste a partir da
complexidade ciclomatica = 2
68 * - Caso de teste 1
69 * - Caso de teste 2
70 */
71
54
3.3. Segundo Caso Pratico dct-ufms
72 // Caso de teste 1
73 public void testAcaoEspecifica_DistritoDesativado ()throws PlcException{
74 distritoVO.setAtivo(Boleano.N);75 assertEquals(distritoBO.acaoEspecifica(
distritoVO), Boleano.S);76 }7778 // Caso de teste 2
79 public void testAcaoEspecifica_DistritoNulo () throwsPlcException{
80 assertEquals(distritoBO.acaoEspecifica(null),null);
81 }8283 /**
84 * Implementacao dos casos de teste para analisar
valores dos parametros
85 * - Caso de teste 3
86 * - Caso de teste 4
87 */
8889 // Caso de teste 3
90 public void testAcaoEspecifica_DistritoAtivoNulo ()throws PlcException{
91 assertEquals(distritoBO.acaoEspecifica(distritoVO), null);
92 }9394 // Caso de teste 4
95 public void testAcaoEspecifica_DistritoJaAtivo ()throws PlcException{
96 distritoVO.setAtivo(Boleano.S);97 assertEquals(distritoBO.acaoEspecifica(
distritoVO), Boleano.S);98 }99
100 // - Teste cenario ’antesDesativar ’
101 /**
102 * Construcao dos casos de teste a partir da
complexidade ciclomatica = 3
103 * - Caso de teste 5
104 * - Caso de teste 6
105 * - Caso de teste 7
106 */
107108 // Caso de teste 5
109 public void testAntesDesativar_DistritoAtivado ()throws PlcException{
55
3.3. Segundo Caso Pratico dct-ufms
110 distritoVO.setAtivo(Boleano.S);111 assertEquals(distritoBO.antesDesativar(
distritoVO , Boleano.N), Boleano.N);112 }113114 // Caso de teste 6
115 public void testAntesDesativar_DistritoDesativado ()throws PlcException{
116 distritoVO.setAtivo(Boleano.N);117 assertEquals(distritoBO.antesDesativar(
distritoVO , Boleano.N), Boleano.N);118 }119120 // Caso de teste 7
121 public void testAntesDesativar_TemFaceQuadra () throwsPlcException{
122 try{123 distritoVO.setAtivo(Boleano.S);124 distritoBO.antesDesativar(distritoVO ,
Boleano.S);125 }catch(PlcException e){126 distritoVO.getAtivo ();127 assertEquals(e.getMessageKey (), "
ucsiatimo028.M3");128 }129 }130131 /**
132 * Implementacao dos casos de teste para analisar
valores dos parametros
133 * - Caso de teste 8
134 * - Caso de teste 9
135 * - Caso de teste 10
136 */
137138 // Caso de teste 8
139 public void testAntesDesativar_DistritoNulo () throwsPlcException{
140 assertEquals(distritoBO.antesDesativar(null ,Boleano.N), null);
141 }142143 // Caso de teste 9
144 public void testAntesDesativar_FaceQuadraNulo ()throws PlcException{
145 distritoVO.setAtivo(Boleano.N);146 assertEquals(distritoBO.antesDesativar(
distritoVO , null), null);147 }
56
3.3. Segundo Caso Pratico dct-ufms
148149 // Caso de teste 10
150 public void testAntesDesativar_DistritoAtivoNulo ()throws PlcException{
151 assertEquals(distritoBO.antesDesativar(distritoVO , Boleano.N), null);
152 }153154 // - Teste cenario ’valida data referencia ’
155 /**
156 * Construcao dos casos de teste a partir da
complexidade ciclomatica = 3
157 * - Caso de teste 11
158 * - Caso de teste 12
159 * - Caso de teste 13
160 */
161162 // Caso de teste 11
163 public voidtestValidaDataReferencia_DataReferenciaAtual ()throws PlcException{
164 assertEquals(distritoBO.validaDataReferencia(new Date()), Boolean.TRUE);
165 }166167 // Caso de teste 12
168 public voidtestValidaDataReferencia_DataReferenciaMaiorDataAtual () throws PlcException , ParseException{
169 assertEquals(distritoBO.validaDataReferencia(amanha(new Date())), Boolean.FALSE);
170 }171172 // Caso de teste 13
173 public voidtestValidaDataReferencia_DataReferenciaMenorDataAtual () throws PlcException , ParseException{
174 assertEquals(distritoBO.validaDataReferencia(ontem(new Date())), Boolean.TRUE);
175 }176177 /**
178 * Implementacao dos casos de teste para analisar
valores dos parametros
179 * - Caso de teste 14
180 */
181182 // Caso de teste 14
183 public void
57
3.3. Segundo Caso Pratico dct-ufms
testValidaDataReferencia_DataReferenciaNulo ()throws PlcException{
184 assertEquals(distritoBO.validaDataReferencia(null), null);
185 }186187 // - Teste cenario ’valida se distrito pode ser
alterado ’
188 /**
189 * Construcao dos casos de teste a partir da
complexidade ciclomatica = 2
190 * - Caso de teste 15
191 * - Caso de teste 16
192 */
193194 // Caso de teste 15
195 public voidtestValidaDistritoPodeSerAlterado_DistritoDesativado () throws PlcException{
196 assertEquals(distritoBO.validaDistritoPodeSerAlterado(Boleano.N),Boolean.FALSE);
197 }198199 // Caso de teste 16
200 public voidtestValidaDistritoPodeSerAlterado_DistritoAtivo ()throws PlcException{
201 assertEquals(distritoBO.validaDistritoPodeSerAlterado(Boleano.S),Boolean.TRUE);
202 }203204 /**
205 * Implementacao dos casos de teste para analisar
valores dos parametros
206 * - Caso de teste 17
207 */
208209 // Caso de teste 17
210 public voidtestValidaDistritoPodeSerAlterado_AtivoNulo ()throws PlcException{
211 assertEquals(distritoBO.validaDistritoPodeSerAlterado(null), null);
212 }213214 // - Teste cenario ’restricaoInclusaoAlteracao ’
58
3.3. Segundo Caso Pratico dct-ufms
215 /**
216 * Construcao dos casos de teste a partir da
complexidade ciclomatica = 3
217 * - Caso de teste 18
218 * - Caso de teste 19
219 * - Caso de teste 20
220 */
221222 // Caso de teste 18
223 public voidtestRestricaoInclusaoAlteracao_MensagemIgualVazio() throws PlcException{
224 distritoVO.setAtivo(Boleano.S);225 distritoVO.setDataReferencia(new Date());226 assertEquals(distritoBO.
restricaoInclusaoAlteracao(distritoVO ,null), Collections.EMPTY_LIST);
227 }228229 // Caso de teste 19
230 public void testRestricaoInclusaoAlteracao_MensagemM4() throws PlcException{
231 distritoVO.setAtivo(Boleano.N);232 distritoVO.setDataReferencia(new Date());233234 List <DsfMensagem > retorno = distritoBO.
restricaoInclusaoAlteracao(distritoVO ,null);
235236 assertEquals(retorno.get (0).getIdMensagem (),"
ucsiatimo028.M4" );237 }238239 // Caso de teste 20
240 public void testRestricaoInclusaoAlteracao_MensagemM5() throws PlcException{
241 distritoVO.setAtivo(Boleano.S);242 distritoVO.setDataReferencia(amanha(new Date
()));243244 List <DsfMensagem > retorno = distritoBO.
restricaoInclusaoAlteracao(distritoVO ,null);
245246 assertEquals(retorno.get (0).getIdMensagem (),"
ucsiatimo028.M5" );247 }248249 /**
59
3.3. Segundo Caso Pratico dct-ufms
250 *
251 * Implementacao dos casos de teste para analisar
valores dos parametros
252 * - Caso de teste 21
253 */
254255 // Caso de teste 21
256 public voidtestRestricaoInclusaoAlteracao_DuasMensagens ()throws PlcException{
257 distritoVO.setAtivo(Boleano.N);258 distritoVO.setDataReferencia(amanha(new Date
()));259260 List <DsfMensagem > retorno = distritoBO.
restricaoInclusaoAlteracao(distritoVO ,null);
261262 assertEquals(retorno.size(), 2);263 }264265 // Metodo executado toda vez que um metodo de caso de
teste finalizado
266 @Override267 protected void tearDown () throws Exception {268 super.tearDown ();269 distritoVO = null;270 }271272 }
4. Eclemma: Analisar resultados
1 - Metodo: ‘acaoEspecifica’ obteve a seguinte analise:— 100% de cobertura das linhas.
2 - Metodo: ‘antesDesativar’ obteve a seguinte analise:— 100% de cobertura das linhas.
3- Metodo: ‘validaDataReferencia’obteve a seguinte analise:— 100% de cobertura das linhas.
4- Metodo: ‘validaDistritoPodeSerAlterado’obteve a seguinte analise:— 100% de cobertura das linhas.
5- Metodo: ‘restricaoInclusaoAlteracao’ obteve a seguinte analise:— 100% de cobertura das linhas.
60
3.3. Segundo Caso Pratico dct-ufms
Figura 3.9: Figura exemplificando o resultado da execucao do Eclemma, alcancando 100%de cobertura das linhas
6 - Como os metodos em questao foram todos cobertos, deve-se passar para oproximo passo.
5. Documentacao: Gerar relatorio
1- Foram encontrados erros e falhas na execucao dos casos de teste, como podeser visto nas Figuras 3.5 e 3.6. Os erros(error) encontrados foram causados pois osmetodos nao conseguiram retornar nenhum resultado, houve erros internos, ondetodos os erros nestes casos foram de null pointer. Ja a falha(failure) aconteceuporque estava sendo esperado um resultado e o metodo retornou outro valor.
2- Plano de casos de teste homologado.
Figura 3.10: Figura exemplificando modelo de relatorio gerado para o caso de uso ManterDistrito, utilizou-se o Ant
O resultado de todo o processo de teste unitario, para o estudo pratico do mundoreal, evidencia que os testes realizados e executados capturaram diversos erros efalhas. Portanto pode–se concluir que os testes realizados foram positivos, ou seja,conseguiram descobrir falhas em diversas linhas de codigo implementadas. Nao cabea etapa de teste de software analisar os motivos que levaram a ocasionar errosna execucao e muito menos oferecer solucoes para os problemas, mas sim indicarque o codigo implementado contem problemas. Todos os materiais gerados foram
61
3.3. Segundo Caso Pratico dct-ufms
entregues a empresa a fim de ajudar e orientar os responsaveis, para que essesanalisem os resultados e tomem as devidas providencias para ajustar e modificar aimplementacao do caso de uso.
O mais importante e que, com o estudo realizado, a empresa podera repensar suaatividade de teste, aprimora-la, institucionaliza-la e, como resultado, oferecer soft-ware de boa qualidade aos clientes.
62
3.3. Segundo Caso Pratico dct-ufms
Figura 3.11: Figura exemplificando modelo de relatorio gerado para o caso de uso ManterDistrito, utilizou-se o Ant
63
3.4. Licoes Aprendidas dct-ufms
3.4 Licoes Aprendidas
Para os alunos autores desta monografia, o projeto foi um grande desafio pois a intencaoera estudar, pesquisar e praticar atividades que o grupo tinha pouco conhecimento. Foramencontradas diversas dificuldades durante a construcao do projeto, as quais, com o anda-mento e esforco do grupo, iam sendo superadas, para que fosse possıvel produzir materiaiscom qualidade e prontos para serem utilizados pelos profissionais que desejassem adquirirmaior conhecimento, tanto teorico quanto pratico, na area.
Durante todas as etapas do projeto, ficou evidente a grande lacuna que existe naarea de teste de software. Observou-se que tanto as Universidades quanto as Empresas deTecnologia deveriam motivar e orientar academicos e profissionais, em relacao ao papel ea importancia da atividade de teste no desenvolvimento de qualquer software. Boa partedas organizacoes desenvolve software sem considerar a atividade de teste, o que afetadiretamente sua qualidade final.
Diante desse cenario, o conhecimento e a pratica adquiridos ao longo do projeto servi-ram para ajudar a enxergar os diferentes testes que sao realizados constantemente emum software. Nao se deve realizar testes apenas uma ou duas vezes, mas planejar paraos tornar automatizados de forma que sejam executados sempre que se julgue necessario.Para poder tornar a atividade de teste de software uma pratica rotineira, deve–se excluira visao negativa em torno do teste de software e encara-lo como um processo crucial parase obter um software de qualidade.
O teste de software, alem de ser importante, possui varias etapas. Este projetoprocurou focar-se em uma etapa, em especial, o teste unitario. O processo de teste unitarioaplicado demonstrou que quando realizado sem planejamento torna-se um processo repe-titivo e caro para aqueles que sao responsaveis pela sua realizacao. Por esse motivo, foramconstruıdos com o intuito de sempre se tornar o mais automatizado possıvel. Por essemotivo, neste trabalho buscou-se automatizar a atividade de teste ao maximo, de formaa tentar minimizar as dificuldades mencionadas.
Conseguiu-se acompanhar a construcao de um software desenvolvido por uma empresareal, a DSF, em que foi obtida uma parceira para a realizacao de testes em regras denegocio em um caso de uso da empresa. Essa experiencia nos proporcionou uma grandeaprendizagem pratica.
64
Capıtulo 4
Conclusao
O teste de sistema e um processo muito custoso e que requer muitos recursos e tempopara ser planejado e executado, porem, e fundamental que seja realizado, pois se trata deuma das etapas de desenvolvimento do sistema que melhoram a qualidade do software.
As empresas ja estao reconhecendo sua importancia e comecam a investir em ferra-mentas e pessoas especializadas. Nao se trata de um processo facil, pois parece ser denatureza “destrutiva”, mas na verdade, visa ao aumento de confianca de um produto pormeio da exposicao do seus problemas.
A fase de estudo de tecnicas de teste e a pesquisa de ferramentas que auxiliam noprocesso de teste foi de grande valia, porque existem muitos estudos na area e assim foipossıvel aumentar o conhecimento. Com esse novo aprendizado, ficou claro que realizartestes nao consiste simplesmente na geracao de casos de teste, mas envolve tambem aquestao de planejamento, gerenciamento, e analise dos resultados.
O objetivo foi alcancado no momento em que se utilizou, no primeiro e segundoexemplo pratico, o plano de caso de teste geral com ferramentas que automatizam oprocesso. A empresa DSF, a qual foi escolhida para a pratica dos testes, foi um dosmaiores desafios. Houve grande dificuldade para se realizar o plano de caso de teste emum codigo que compoe um sistema complexo e que ainda, uma vez projetado, nao visavao uso de testes unitarios ja que a empresa nao possui um processo de teste definido.
A escolha pelo teste unitario e apenas o inıcio de um plano de teste de software. Aindafaltam as etapas de teste de integracao, sistemas e aceitacao. Por isso, o grupo sugere queem futuros trabalhos sejam exploradas as outras etapas de teste de software.
65
Referencias Bibliograficas
Angelo, F. (2006). Qualidade de Software Vai Alem de Testes. Computer World.
Araujo, M. A. P. (2008). Melhorias de Processo de Software. Engenharia de Software -Magazine, (3).
Barbosa, E. F., Maldonado, J. C., Vincenzi, A. M. R., Delamaro, M. E., Souza, S. R. S.,and Jino, M. (2004). Introducao ao Teste de Software. Technical report, Instituto deCiencias Matematicas e de Computacao, Universidade de Sao Paulo.
Craig, R. D. and Jaskiel, S. P. (2002). Systematic Software Testing. Artech House Pub-lishers, Boston.
Pressman, R. S. (2007). Engenharia de Software. Pearson, Sao Paulo - SP.
Sommerville, I. (2005). Engenharia de Software. Addison-Wesley, Sao Paulo - SP.
66
Referencias Bibliograficas dct-ufms
Bibliografia Adicional
Abramti, http://www.abramti.org.br/modules/news/article.php?storyid=34,Data de pesquisa: 01/12/2008
Apodora, http://www.apodora.org/, Data da pesquisa: 29/07/2008.
Check22, http://sourceforge.net/projects/check/, Data da pesquisa: 29/07/2008.
Continuous Teste para Eclipse, http://ct-eclipse.tigris.org/, Data da pesquisa:28/07/2008.
CSUNIT, http://www.csunit.org, Data da pesquisa: 29/07/2008.
CUT, http://falvotech.com/content/cut/3/, Data da pesquisa: 28/07/2008.
CUTEST, http://cutest.sourceforge.net/, Data da pesquisa: 23/07/2008.
Dave’s Unit Test, http://sourceforge.net/project/showfiles.php?group_id=
217691, Data da pesquisa: 28/07/2008.
DBFeeder, http://dbfeeder.sourceforge.net/Manual.htm, Data da pesquisa:30/07/2008.
DejaGNU, http://www.gnu.org/software/dejagnu/, Data da pesquisa: 30/07/2008.
ECLEMMA, http://sourceforge.net/projects/eclemma, Data da pesquisa:04/08/2008.
Eclemma - Java Code Coverage For Eclipse, http://www.eclemma.org/, Data depesquisa: 30/08/2008.
IBM Rational Functional Tester, http://www.ibm.com/developerworks/rational/
library/06/1205_kelly/, Data da pesquisa: 28/07/2008.
ISPIS, http://lens-ese.cos.ufrj.br/ese/index.php?option=com_docman\&task=
doc_details\&gid=4\&lang=pt_br, Data da pesquisa: 28/07/2008.
JavaTT, http://javatt.com/en;http://javatt.com/en/documentation_javatt_
0.6.php, Data da pesquisa: 04/08/2008.
Jemmy, http://jemmy.netbeans.org/, Data da pesquisa: 30/07/2008.
JF-UNITTEST, http://confix.sourceforge.net/, Data da pesquisa: 23/07/2008.
JSTester, http://jstester.sourceforge.net/, Data da pesquisa: 04/08/2008.
67
Referencias Bibliograficas dct-ufms
JUnit, http://sourceforge.net/projects/junit/, Data da pesquisa: 29/07/2008.
Marathon, http://www.marathontesting.com/Home.html, Data da pesquisa:29/07/2008.
Massol, V., Husted, T. , JUnit em Acao, Ciencia Moderna, Rio de Janeiro - RJ,2005.
METRICS, http://metrics.sourceforge.net/, Data da pesquisa: 04/08/2008.
Paiva, D. M. B., (2008), Notas de Aula.
QTUNIT, http://www.uwyn.com/projects/qtunit/, Data da pesquisa: 21/07/2008.
SELENIUM, http://selenium.openqa.org/, Data da pesquisa: 28/07/2008.
Software Metrics, http://open.ncsu.edu/se/tutorials/metrics/, Data de pesquisa:30/08/2008.
Tiobe Software, http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html,Data de pesquisa: 01/12/2008
Utex, http://utex.tigris.org/, Data da pesquisa: 29/07/2008.
XmlMessageTest, http://xmlmessagetest.tigris.org/, Data da pesquisa:29/07/2008.
68