TESTE DE SOFTWARE - infobitsolucoes.com de Software... · Apresentar de forma dinâmica e...

Copyright © 2011, ESAB – Escola Superior Aberta do Brasil

1

MÓDULO DE:

TESTE DE SOFTWARE

AUTORIA:

Me. PEDRO HENRIQUE MANNATO COUTINHO



2

Módulo de: Teste de Software

Autoria: Pedro Henrique Mannato Coutinho

Primeira edição: 2011

CITAÇÃO DE MARCAS NOTÓRIAS

Várias marcas registradas são citadas no conteúdo deste Módulo. Mais do que simplesmente listar esses

nomes e informar quem possui seus direitos de exploração ou ainda imprimir logotipos, o autor declara estar

utilizando tais nomes apenas para fins editoriais acadêmicos.

Declara ainda, que sua utilização tem como objetivo, exclusivamente na aplicação didática, beneficiando e

divulgando a marca do detentor, sem a intenção de infringir as regras básicas de autenticidade de sua

utilização e direitos autorais.

Todos os direitos desta edição reservados à

ESAB – ESCOLA SUPERIOR ABERTA DO BRASIL LTDA

http://www.esab.edu.br

Av. Santa Leopoldina, nº 840/07

Bairro Itaparica – Vila Velha, ES

CEP: 29102-040



3

Apresentação

O software passou a ser peça chave na competitividade de muitas empresas, fazendo

com que suas falhas provocassem diversos tipos de prejuízos. Nesse cenário, para

garantir a qualidade dos softwares à área de teste vem ganhando cada vez mais

importância e notoriedade.

Para obter a atenção necessária, os testes devem ser tratados com uma abordagem mais

sistemática, deixando de ser uma atividade dentro do processo de desenvolvimento, e

passando a ter um processo próprio, com etapas, atividades, artefatos, técnicas, equipe,

ambiente e ferramentas.

Objetivo

Apresentar de forma dinâmica e agradável os conceitos relacionados aos testes de

software e a sua importância, em conjunto com demonstrações práticas. Proporcionar ao

aluno o aprendizado necessário para colocar em prática os principais aspectos dos testes

de software.

Para atingir esse objetivo, foram intercaladas unidades de conceituação e

recomendações, com outras de demonstração de ferramentas gratuitas e ricas em

funcionalidades, para apoiar diferentes atividades e etapas do processo de Teste do

Software.

Ementa

Apresentação dos seguintes temas: testes estáticos, dinâmicos, funcionais (caixa-preta),

estruturais (caixa-branca), tipos e níveis de testes, investimento em teste, custo da falha e

da correção, o processo de teste, planejamento, ambiente, equipe, casos de teste,


4

execução, gestão dos defeitos, revisão e inspeção, desenvolvimento orientado a testes

(TDD) e integração contínua. São apresentadas também 8 ferramentas gratuitas para:

cobertura de código, teste unitário, objetos "substitutos" (mock objects), gestão de

defeitos, gestão do processo de teste, teste de estresse e de performance, testes de

aplicações web e integração contínua.

Sobre o Autor

Mestre em Informática (UFES -2007), Graduado em Ciência da Computação (UFES-

2004).

A Dissertação de Mestrado rendeu o terceiro lugar no prêmio de dissertações do SBIE

2008 (Simpósio Brasileiro de Informática na Educação).

Diretor Executivo e sócio fundador da empresa Projeta Sistemas de Informação. Já foi

Vice-Presidente de Associativismo e Financeiro da ASSESPRO-ES.

Professor de Pós-Graduação Lato-Sensu em disciplinas presenciais e on-line. Faz parte

do corpo de consultores de tecnologia do SEBRAE-ES. Possui experiência atuando como

Gerente de Projeto, Analista de Sistema, Analista de Processos de Negócio (BPM),

Desenvolvedor, Pesquisador de Novas Tecnologias, Analista de Testes, dentre outros.

Atuou em projetos que tinham como clientes: Arcelor Mittal, Receita Federal, IBGE,

Sebrae, Grupo Coimex, ESAB, dentre outros. Atuou como analista e desenvolvedor do

software para o gerenciamento de empresas do mercado rent a car, ganhador do 1º

Prêmio do Pólo de Software do Espírito Santo e um dos quatro finalistas do 6º Encontro

Nacional de Tecnologia e Negócios - Rio Info.


5

SUMÁRIO

UNIDADE 1 ......................................................................................................................... 7

Introdução ....................................................................................................................... 7

UNIDADE 2 ....................................................................................................................... 10

Conceitos de Testes I .................................................................................................... 10

UNIDADE 3 ....................................................................................................................... 13

Conceitos de Testes II.....................................................................................................13

UNIDADE 4 ....................................................................................................................... 17

Custos de Testar, da Correção e o Retorno de Investimento em Testes ...................... 17

UNIDADE 5 ....................................................................................................................... 23

Custos das Falhas ......................................................................................................... 23

UNIDADE 6 ....................................................................................................................... 26

O Processo de Teste ..................................................................................................... 27

UNIDADE 7 ....................................................................................................................... 32

Planejamento dos Testes .............................................................................................. 32

UNIDADE 8 ....................................................................................................................... 38

Ambiente de Testes ....................................................................................................... 38

UNIDADE 9 ....................................................................................................................... 43

A Equipe e os Papéis nos Testes .................................................................................. 43

UNIDADE 10 ..................................................................................................................... 48

Técnicas Estáticas - Revisão e Inspeção ...................................................................... 48

UNIDADE 11 ..................................................................................................................... 51

Casos de Teste ............................................................................................................. 51

UNIDADE 12 ..................................................................................................................... 56

Execução dos Testes .................................................................................................... 56

UNIDADE 13 ..................................................................................................................... 59

Gestão de Testes - Ferramenta TestLink ...................................................................... 59

UNIDADE 14 ..................................................................................................................... 64

Gestão de Defeitos ........................................................................................................ 64

UNIDADE 15 ..................................................................................................................... 68


6

Gestão de Defeitos - Ferramenta Mantis I ..................................................................... 68

UNIDADE 16 ..................................................................................................................... 73

Gestão de Defeitos - Ferramenta Mantis II.....................................................................73

UNIDADE 17 ..................................................................................................................... 77

Cobertura de Código - Ferramenta EclEMMA ............................................................... 77

UNIDADE 18 ..................................................................................................................... 80

Testes de Unidade e Integração - Ferramenta JUnit ..................................................... 80

UNIDADE 19 ..................................................................................................................... 86

Testes com Objetos Substitutos ou "Falsificados" (Mock Objects) - Ferramenta Mockito ...................................................................................................................................... 86

UNIDADE 20 ..................................................................................................................... 92

Desenvolvimento Orientado a Testes (TDD - Test Driven Devlopment) ....................... 92

UNIDADE 21 ..................................................................................................................... 96

Exemplo de TDD na Prática .......................................................................................... 96

UNIDADE 22 ................................................................................................................... 102

SELENIUN - Ferramenta para Gravar/Executar Testes em Browsers ........................ 102

UNIDADE 23 ................................................................................................................... 105

SELENIUN - Ferramenta para Gravar/Executar Testes em Browsers (Continuação) . 105

UNIDADE 24 ................................................................................................................... 109

SELENIUN - Ferramenta para Gravar/Executar Testes em Browsers (Continuação) . 109

UNIDADE 25 ................................................................................................................... 114

Teste de Performance e Estresse - Ferramenta JMeter .............................................. 114

UNIDADE 26 ................................................................................................................... 118

Teste de Performance e Estresse - Ferramenta JMeter (Continuação) ...................... 118

UNIDADE 27 ................................................................................................................... 122

Integração Contínua .................................................................................................... 122

UNIDADE 28 ................................................................................................................... 126

Integração Contínua - Ferramenta Jenkins I ............................................................... 126

UNIDADE 29 ................................................................................................................... 131

Integração Contínua - Ferramenta Jenkins II .............................................................. 131

UNIDADE 30 ................................................................................................................... 136

Considerações Finais .................................................................................................. 136


7

UNIDADE 1

Objetivo: Realizar uma apresentação inicial do conteúdo do Módulo de Teste de Software

Introdução

Bem vindo ao Módulo Teste de Software!

O avanço da tecnologia nas últimas décadas em áreas que vão dos hardwares até as

linguagens de programação, proporcionaram o surgimento de milhares de software. A

utilização da Internet potencializou ainda mais esse fato, fazendo com que diversas

aplicações computacionais fizessem parte do nosso dia a dia. Assim, o software passou a

ser peça chave na competitividade de muitas empresas, fazendo com que suas falhas

provocassem diversos tipos de prejuízos. Nesse cenário, para garantir a qualidade dos

softwares, a área de teste foi ganhando cada vez mais importância.

Até a década de 90, os testes eram realizados na maioria das vezes pelos próprios

desenvolvedores, e eram tratados como uma atividade que tinha pouco tempo disponível,

no cronograma do projeto de software, para ser realizada. Desde então, diversos artigos,

ferramentas e livros sobre testes foram lançados, mas assim mesmo é comum ver

empresas que não dedicam a atenção necessária a essa área para garantia da qualidade.

Portanto, o objetivo deste Módulo é apresentar os principais pontos envolvidos com o

teste de software, com uma abordagem mais sistemática; deixando de ser uma atividade

dentro do processo de desenvolvimento, e passando a ter um processo próprio, com

etapas, atividades, artefatos, ambiente, técnicas, equipe e ferramentas.

Mesmo com todo avanço em relação aos testes, nos últimos anos; o teste de software

não é uma "ciência exata". No entanto, teste exaustivo é impossível, e para realizar os

testes adequadamente é importante realizar uma avaliação de risco.

A análise de risco é uma parte importante dos testes de software, visto que vai determinar

as áreas que precisam ser mais cuidadosamente testadas e, em qual momento, se pode


8

considerar que os testes realizados foram suficientes para garantir uma confiança

adequada para liberar o software para produção.

Para atingir o objetivo, este Módulo foi baseado em livros, artigos de especialistas,

revistas especializadas e manuais de ferramentas. Para fornecer uma abordagem

conceitual aliada à prática, 8 ferramentas gratuitas, relacionadas com diferentes partes do

teste de software, serão apresentadas.

O objetivo da apresentação dessas 8 ferramentas é propiciar ao aluno o conhecimento

dos principais benefícios, facilidade de uso e o momento adequado para usar cada tipo de

ferramenta. Assim, o Módulo não tem a pretensão de abranger todos os aspectos dessas

ferramentas, até porque, o manual delas é extenso, impossibilitando abordar em um

módulo.

A figura a seguir apresenta algumas das bibliografias utilizadas como base para à

elaboração deste Módulo.

Figura 1 – Algumas referências que serviram como base para este Módulo

Um dos indicadores da importância e aumento de notoriedade dos testes de software é o

surgimento de várias certificações. Dentre elas, é importante citar a Certificação Brasileira


9

em Teste de Software (CBTS) e a Qualificação Internacional de Teste de Software

(ISTQB - Internacional Software Testing Qualification), cujas referências também foram

consultadas para a elaboração deste Módulo.

Os modelos de processo de melhoria de software como CMMI (Capability Maturity Model

Integration) e o MPS.BR (Melhoria de Processos do Software Brasileiro) exigem a

implantação de testes de software. Por exemplo, para conquistar o nível 3 do CMMI é

preciso adotar uma abordagem sistemática em relação aos testes, que se encontra nas

áreas de Verificação e Validação deste modelo.

É importante notar que as metodologias ágeis como o XP (eXtreme Programming)

contribuíram com os conceitos de Integração Contínua, Desenvolvimento Orientado a

Testes (TDD) e ferramentas de testes unitários no modelo xUnit, que serão estudadas

neste Módulo. Apesar de a origem ter sido em metodologias ágeis, qualquer metodologia

de desenvolvimento pode se beneficiar dessas práticas.

Organização do Conteúdo

Nas próximas duas unidades deste Módulo, serão abordados conceitos utilizados nas

demais unidades. Portanto, as Unidades 2 e 3 apresentam conceitos como testes

estáticos, dinâmicos, funcionais (caixa-preta), estruturais (caixa-branca), tipos e níveis de

testes. As unidades seguintes apresentam conceitos relacionados com o custo do teste,

custo da falha e da correção; o processo de teste; planejamento; ambiente; equipe; casos

de teste; execução; gestão dos defeitos; revisão e inspeção; desenvolvimento orientado a

testes (TDD) e integração contínua.

Serão apresentadas também 8 ferramentas gratuitas para: cobertura de código, teste

unitário, objetos "substitutos" (mock objects), gestão de defeitos, gestão do processo de

teste, teste de estresse e de performance, testes de aplicações web e integração

contínua.


10

UNIDADE 2

Objetivo: Conhecer os principais conceitos sobre os testes, que serão utilizados no decorrer deste Módulo

Conceitos de Testes I

Se os testes são tão importantes, por que normalmente não se testa adequadamente?

Um dos principais fatores para responder essa pergunta é entender que a pressão por

menores prazos e valores negociados para desenvolver um software, dificilmente

contempla a realização de testes de forma adequada. Os testes precisam de um

investimento inicial maior, mas como será visto, ao longo deste módulo, os prejuízos

provocados pelas falhas costumam justificar o investimento em um processo de testes.

Os softwares são desenvolvidos por seres humanos, que por mais dotados de

competências, não são perfeitos, sendo passíveis de cometer erros. A verdade é que

infelizmente os erros estarão presentes no software, e se a equipe de desenvolvimento

não encontrá-los, o cliente vai encontrar, já que cada vez que ele interage com o software,

ele está "exercitando" uma funcionalidade.

Delamaro, Maldonado e Jino citam no livro "Introdução ao Teste de Software" que o

desenvolvimento de software está sujeito a diversos tipos de influências e problemas que

acabam por gerar um software diferente do que o cliente esperava. Dentre os diversos

fatores que podem causar esses problemas, eles identificam que a maioria é ocasionado

por uma mesma origem, o erro humano.

Portanto, os testes devem ser realizados de uma maneira sistemática, para evitar o

acontecimento de uma das "Leis de Murphy": "Se alguma coisa pode dar errado, dará. E

mais, dará errado da pior maneira, no pior momento e de modo que cause o maior dano

possível."


11

Exceto em casos triviais, a execução de testes exaustivos que testam todas as

possibilidades de combinações, entradas, etc., não são viáveis. Pode-se citar como

exemplo, uma demonstração simples apresentada por Falbo (2008):

Suponha um programa que calcule o exponencial de números inteiros x e y (xy). Para

testar todas as entradas possíveis todos os números inteiros de x e y combinados devem

ser testados, gerando uma cardinalidade de 2n * 2n, sendo "n" o número de bits usados

para representar um inteiro. Em uma arquitetura de 32 bits, a cardinalidade seria 264

(232*232). Se cada teste puder ser realizado em 1 milissegundo, seria necessário

aproximadamente 5,85 milhões de séculos para executar todos os testes. Adicionalmente

mesmo que o teste exaustivo fosse executado, ele não garantiria que o software

corresponde à sua especificação. Suponha que ao invés do xy o cliente tenha especificado

a raiz de x por y (y√ x), e o desenvolvedor por equívoco implementou a função

apresentada no exemplo; esse erro não seria identificado pelo teste exaustivo, e sim pela

revisão dos requisitos ou teste de aceitação.

Portanto, como afirmou Djkistra “O teste não pode nunca demonstrar a ausência de

defeitos, apenas sua presença”.

Mesmo não sendo possível realizar testes exaustivos para provar que o software está

livre de defeitos a condução sistemática de testes em conjunto com as definições de

critérios, riscos e prioridades contribuem para aumentar a qualidade e confiança no

sistema.

Testes Estáticos x Testes Dinâmicos

As atividades relacionadas ao teste do software em si não envolvem somente a execução

do programa, que é o teste dinâmico. Existem também os testes estáticos, que não

precisam da execução de um software (ou nem mesmo a sua existência) para serem

realizados. Os testes estáticos podem ser aplicados a diferentes artefatos como a revisão

de documentos de requisitos, análise, do próprio código fonte, etc.


12

Testes Funcionais (Caixa-preta) x Estruturais (Caixa-branca)

Os testes funcionais também são conhecidos como "teste caixa-preta", pelo fato do

testador não precisar conhecer os detalhes da codificação. Nesse tipo de teste o testador

informa os dados de entrada e verifica se a saída/resultado está de acordo com o que era

esperado. Portanto, esse tipo de teste não tem como objetivo saber como a

funcionalidade foi implementada, mas sim quais são os resultados apresentados.

Avaliando somente a entrada e a saída, o teste de caixa-preta visa identificar defeitos do

tipo:

• Se o sistema aceita entradas incorretas;

• Se a saída produzida está correta;

• Se existem erros na interface;

• Se alguma funcionalidade está faltando;

• Dentre outros.

Já os testes estruturais, ou "testes caixa-branca" levam em consideração a estrutura do

código fonte para identificar a implementação e se os diferentes caminhos estão sendo

cobertos por algum tipo de teste. Assim, os testes serão elaborados para: testar as

decisões lógicas (verdadeiro/falso), testar os "loops" até o limite, as variáveis estáticas e

dinâmicas, dentre outros.

O teste de caixa-branca não substitui o teste de caixa-preta, e vice-versa. Eles são

utilizados em conjunto; cada um com um objetivo distinto.

Figura 2 – Teste Caixa-preta e Teste Caixa-branca


13

UNIDADE 3

Objetivo: Objetivo: Conhecer os principais conceitos sobre os testes, que serão utilizados no decorrer deste Módulo

Conceitos de Testes II

Níveis de Testes

Os níveis de testes normalmente são classificados como: teste unitário, teste de

integração, teste de sistema e teste de aceitação.

Os testes unitários são realizados nas menores unidades do software, que normalmente

são os métodos ou funções. Usualmente são os próprios desenvolvedores que realizam

os testes unitários do próprio código. O seu objetivo é buscar por erros de lógica e

programação, nas unidades em separado, de forma a garantir que essas unidades

funcionem corretamente e isoladamente. A justificativa clara para realizar os testes de

unidade é:, se uma unidade não funcionar isoladamente, ao ser integrada com outras

unidades, o erro será propagado e mais tempo será gasto para identificá-lo. Os testes

unitários podem ser realizados após a implementação da unidade, ou até mesmo antes

de seu código ser implementado, sendo essa última uma abordagem de metodologias

ágeis (Mais detalhes, a respeito de desenvolvimento orientado a testes, serão abordados

adiante).

Os testes de integração verificam se as partes que funcionavam isoladamente continuam

a funcionar após serem combinadas. Portanto, são verificadas as integrações entre

unidades, componentes, sistemas, camadas, etc.

As integrações podem ser do tipo "Big-Bang" ou incremental.

A integração Big-Bang consiste da realização do teste após todas as unidades,

componentes, etc.; serem integrados, testando tudo de uma só vez. A integração

incremental consiste em integrar e testar o programa gradativamente, começando com


14

uma integração pequena e testando; constituindo uma nova integração somente quando

os testes da integração menor forem bem sucedidos. A integração Big-Bang é mais

arriscada, porque quanto maior for a abrangência da integração mais difícil será para

identificar a parte que originou a falha. Sem contar que testar a integração, após tudo ter

sido desenvolvido, faz com que os erros sejam encontrados tardiamente. Portanto, para

evitar esses tipos de problemas, recomenda-se o uso da Abordagem Incremental.

Testes de sistema avaliam o comportamento do sistema como um todo. Além das

funcionalidades, as características não funcionais como: performance, segurança,

usabilidade, dentre outros, são avaliados. Esses quesitos podem ser avaliados também

nos outros níveis de teste, e devem ser feitos por completo nos testes de sistema. Nesse

nível, é importante que o ambiente de teste se pareça, ao máximo, com o ambiente de

produção, de forma que os testes reproduzam o máximo possível o uso real.

Testes de aceitação são realizados pelos clientes e/ou usuários do sistema com o objetivo

de verificar se o sistema está atendendo ao que era pretendido e foi especificado. Esse

nível não tem como objetivo caçar defeitos e sim verificar se o sistema está "conforme".

Engana-se quem pensa que esses testes devem ser realizados somente ao final do

desenvolvimento. Eles devem ser realizados o quanto antes, para que os desvios possam

ser corrigidos enquanto há tempo e não tenham sido propagados. Deixar os testes de

aceitação somente para o final representa um risco altíssimo de reprovação do cliente,

gerando diversos tipos de prejuízos que englobam o custo do retrabalho, perda do tempo

certo para lançar o produto, dentre outros.

Técnicas de Testes

A seguir, serão apresentadas algumas técnicas de teste.

• Teste de regressão: consiste em testar novamente o software (ou partes dele),

após o desenvolvimento de uma mudança. Assim, o objetivo é verificar se a

introdução de uma mudança, como por exemplo, novo código ou até mesmo a

correção de um defeito, não provocou um novo defeito em uma parte do software

que funcionava corretamente, ou seja, verificar que não ocorreu nenhum "efeito

colateral". A reexecução dos testes muitas vezes não é realizada da forma


15

adequada por ser encarada como uma tarefa cansativa e repetitiva, mas é preciso

avaliar o risco de uma parte que funcionava apresentar defeitos. Como os testes de

regressão são realizados muitas vezes, se tornam bons candidatos a serem

automatizados.

• Teste de estresse: o objetivo do teste de estresse é avaliar como o sistema se

comporta em condições extremas. Dessa forma, ele deve ser realizado para

consumir os recursos disponíveis de forma anormal, testando: restrições de

memória, espaço em disco, CPU, dentre outros. Para isso, testa-se com

quantidade elevada de acessos simultâneos, volume de dados acima da média

esperada, etc. Nessas condições o comportamento do sistema será avaliado. É

importante que o ambiente de testes seja o mais parecido possível com o ambiente

de produção.

• Teste de recuperação: verifica se o sistema será restabelecido à sua operação

normal e de forma íntegra após ocorrer alguma falha, como por exemplo: queda da

rede, falha de hardware, perda de acesso ao banco de dados, dentre outros. Para

tanto, esses e outros tipos de falhas são provocadas pelo testador. O teste de

recuperação avalia não só a recuperação automática do sistema, mas também os

procedimentos manuais necessários. Dessa forma, os testes avaliam

procedimentos com respectivos checklilsts e podem envolver inclusive a

restauração de backup. Portanto, verifica-se também se o backup está sendo

realizado e armazenado adequadamente. Outro ponto avaliado é a quantidade de

tempo necessário para o software se restabelecer, depois da realização dos

procedimentos.

• Teste de performance: o objetivo do teste de performance é avaliar se o sistema

consegue obter um desempenho determinado em quesitos como, tempo de

resposta, utilização do hardware, dentre outros. Não deve ser confundido com o

teste de estresse, visto que, nesse caso, o objetivo é verificar se a performance

está como esperada em condições normais, e não em condições extremas.

• Teste de segurança: os testes de segurança são executados para garantir que os

mecanismos de segurança do software vão protegê-lo em relação à integridade,

confidencialidade das informações e proteção do software. Esse tipo de teste pode


16

necessitar de contratação de terceiros, visto que especialistas poderão utilizar

técnicas e conhecimentos específicos para invadir o software, sendo que esses

conhecimentos não costumam ser de conhecimento de analistas, desenvolveres e

testadores em geral.

• Teste paralelo: a referência do CBTS chama de teste paralelo a execução da nova

versão do software em conjunto com uma versão antiga, para comparar se os

resultados apresentados são iguais.

Em relação à performance de um site, a revista Exame PME, de Junho de 2011, traz uma informação interessante. Na reportagem "Quem é mais rápido vende mais" são apresentados dados de uma pesquisa informando que:

• Cada 1 segundo que um site demora a mais para carregar; significa perda de 7% das vendas

• 57% dos consumidores abandonam um site depois de esperar 3 segundos para visualizar os dados

• 80 % desses consumidores não voltam ao site por pelo menos 6 meses • Desde 2008, a Amazon estima ter aumentado suas receitas em 1%, cada vez

que suas páginas ficaram um décimo de segundo mais rápidas.


17

UNIDADE 4

Objetivo: Conhecer os custos envolvidos com os testes de software, bem como o retorno de investimento proporcionado.

Custos de Testar; da Correção e o Retorno de Investimento em Testes.

Custos de Testar

O autor do livro "The Art of Software Testing" (A Arte de Testar Software), Glenford Myers

estima que 50% do custo total do projeto são gastos com as atividades relacionadas ao

teste de software. Embora outros autores apresentem estimativas diferentes é importante

identificar onde esses custos estão alocados.

O teste de software consome recursos principalmente em:

• Profissionais: horas gastas pelos profissionais da equipe (desenvolvedores,

analistas de teste, testadores, etc.) com atividades de testes, custos com

treinamento da equipe, dentre outros.

• Equipamentos: máquinas necessárias para permitir a criação de um ambiente de

teste adequado, que permita simular o ambiente de produção.

• Ferramentas: softwares necessários para gerenciar o processo de teste e os

defeitos, preparar as bases de dados, realizar testes unitários, de integração,

aceitação, regressão, e demais testes.

Portanto, para implantar um processo de teste de software será necessário investir um

valor maior no início. Entretanto, o retorno desse investimento tende a ser muito maior do

que se os testes não fossem realizados de forma planejada e organizada.


18

A figura abaixo demonstra, de forma simples, o aumento do investimento inicial com a

implantação de um processo de testes bem como retorno de investimento proporcionado.

Figura 3 – Economia proporcionada ao investir em testes de software

Como se pode perceber, na imagem, a parte da esquerda representa um projeto que não

possui um processo de teste formalizado. Mesmo não sendo formalizado, esse projeto

consome recursos com testes; visto que alguns testes aleatórios são realizados pelos

desenvolvedores e eventualmente por algum outro membro da equipe. Já no projeto da

direita, que possui um processo de teste estabelecido, o custo com a realização dos

testes aumenta em relação ao anterior (custo com pessoas, ferramentas, etc.) e o custo

das falhas diminui, proporcionando uma economia ao longo do tempo. O "Custo da

Falha", representado de forma resumida na figura, engloba o custo do retrabalho,

correção e prejuízos ocasionados pela falha; desde prejuízo de imagem da equipe

desenvolvedora até prejuízos financeiros, como por exemplo, processos judiciais.


19

Custo da Correção

No processo de desenvolvimento de software com as etapas de: Especificação de

Requisitos, Análise, Projeto, Implementação e Implantação; quanto mais tarde um defeito

for encontrado, maior será o custo para corrigi-lo. E não é difícil visualizar o motivo desse

aumento, visto que uma simples declaração errada, nos requisitos, pode gerar de duas a

três decisões equivocadas na etapa de análise/projeto, podendo ocasionar uns vinte erros

introduzidos no desenvolvimento (Black, 2002). É como se fosse uma bola de neve que

aumenta na medida em que ela desce morro abaixo.

Essa percepção de que: quanto mais cedo o defeito for encontrado mais barato será a

sua correção é antiga. Barry Boehm já abordava esse tópico em seu artigo de 1976 e

Glenford Myers em seu livro "The art of sotware testing" (A arte de testar software) de

1979. A declaração de Myers ficou famosa, sendo conhecida como a “Regra 10 de

Myers”, em que ele alega que o custo de corrigir um defeito aumenta 10x por cada etapa

em que o projeto de software avança.

O custo de correção aumenta ainda mais se o erro for detectado externamente (pelo

cliente), após a entrega do software, do que internamente pela equipe

desenvolvedora/testadora. O especialista Rex Black (mais detalhes sobre ele ao final

desta unidade) estima que um defeito encontrado por um desenvolvedor, custa em média

$ 10 para ser corrigido, enquanto que, se for identificado por um testador custará $100 e

pelo cliente $ 1000. Para visualizar melhor esses custos é importante pensar no processo.

Quando o desenvolvedor identifica o defeito, ele vai e corrige. Caso esse mesmo defeito

seja identificado por um testador, ele terá que reportar para que o desenvolvedor o

identifique e conserte. Em seguida, uma nova versão deverá ser disponibilizada para o

testador verificar se o erro foi de fato corrigido e se nenhum outro foi introduzido com a

correção (realização do teste de regressão). Portanto, pode-se perceber como é mais

caro quando o defeito é identificado pelo testador.

Quando o defeito é identificado pelo cliente, além dos passos descritos anteriormente,

existe o aumento do custo com o suporte técnico que atenderá o cliente e de implantar a

nova versão do software, sem contar os possíveis custos intangíveis com processos

judiciais e impactos, na reputação da empresa desenvolvedora (Black,2010).


20

Adicionalmente, com o passar dos anos, os custos podem aumentar de maneira

exorbitante, visto que pode ser difícil encontrar algum desenvolvedor que trabalhou no

software (problema agravado se o software não tiver uma documentação adequada) e/ou

então encontrar um profissional com experiência adequada em uma linguagem de

programação/plataforma que se tornou obsoleta.

Então, se é fácil perceber pelos motivos citados que quanto mais cedo o defeito for

identificado e corrigido, menor será o seu custo, por que muitos gestores ignoram a

realização adequada de testes? A resposta é: eles não visualizam o teste como um

investimento.

Normalmente enxergam o teste como uma atividade custosa, que requer muito tempo e

investimento e que não ajudará o software ficar pronto mais cedo, em um cenário que, na

maioria das vezes, a pressão por prazo e as margens de lucro são bem pequenas.

Portanto, para visualizar que o teste deve ser visto como um investimento; é importante

observar a situação descrita a seguir.

Retorno de Investimento

Para entender melhor o retorno de investimento proporcionado pelos testes, deve-se

tomar como base o seguinte estudo de caso hipotético, apresentado por Rex Black.

Um software implantando em um cliente possui uma nova versão liberada a cada 3

meses. Em média, cada nova versão possui 1000 novos defeitos. A equipe

desenvolvedora desse software encontra em média 250 erros antes de liberar a versão,

sendo que o restante (750) é encontrado pelo cliente. Tendo como base a estimativa

anterior do próprio Rex Black, que um erro encontrado por um desenvolvedor custa em

média $10 e pelo cliente custa $ 1000, esse cenário, que não possui um processo formal

de teste, gera um custo de $750.000 por versão, e uma insatisfação imensa no cliente.

Para tentar melhorar essa situação, o gerente do projeto consegue investir $ 70.000 por

versão em testes manuais para minimizar os impactos. Sendo assim, a equipe dedicada

para testes identifica mais 350 defeitos que são corrigidos antes de lançar a versão.


21

Partindo da estimativa que cada defeito encontrado por um testador custa em média

$100, o retorno do investimento é 350%, conforme apresentado na tabela a seguir.

Opções para Investimento em Testes (Adaptado de Rex Black,2010)

TESTES

Sem

Processo

Formal

Processo

Manual

Teste

Automatizado

Equipe $ 0 $ 60.000 $ 60.000

Infraestrutura $ 0 $10.000 $10.000

Ferramentas e Automatização $ 0 $ 0 $12.500

Total $ 0 $ 70.000 $ 82.500

Desenvolvimento

Defeitos Encontrados 250 250 250

Custo da Correção 2500 2500 2500

Testes


Custo da Correção 0 35.000 50.000

Suporte ao usuário


Custo da Correção 750.000 400.000 250.000

Custo da Qualidade

Investimento $ 0 $ 70.000 $ 82.500

Custo da Correção $ 752.500 $ 437.500 $ 302.500

Total $ 752.500 $ 507.500 $ 385.000

Retorno do Investimento N/A 350% 445%

Tabela 1 – Retorno de Investimento em Testes adaptado de (Black, 2010)

Percebendo o retorno do investimento, o gerente do projeto consegue pleitear um

investimento de mais $12.500, por versão, para investir em automatização dos testes,

encontrando 150 defeitos a mais. Dessa forma, o retorno de investimento obtido seria de

445%.


22

Apesar desse estudo de caso ser hipotético, o renomado especialista Rex Black afirma ter

presenciado retorno de investimento, em testes, variando de 50% a 3200%.

Entretanto, assim como qualquer outro investimento, somente disponibilizar a verba não é

garantia de sucesso, visto que existem formas corretas e erradas de se investir. Se o

dinheiro não for investido com a equipe, ferramentas e técnicas adequadas, o resultado

pode ser negativo e frustrante.

Conheça Rex Black:

Rex Black é um dos especialistas mais reconhecidos em teste de software. Autor de livros relacionados aos testes, dentre eles o popular "Managing the Test Process" com mais de 25.000 cópias vendidas ao redor do mundo. Também é palestrante e autor de vários artigos (muitos deles podem ser encontrados em http://www.rbcs-us.com/).

Durante 4 anos foi presidente do ISTQB e um dos autores do Syllabus da certificação desse instituto.


23

UNIDADE 5

Objetivo: Conhecer alguns prejúizos causados por falhas de software, visualizando que em alguns casos os custos podem ser muito altos

Custos das Falhas

O National Institute of Standards and Technology (NIST), ou em português Instituto

Nacional de Tecnologia e Padrões, é uma agência do Departamento de Comércio dos

Estados Unidos. Em 2002 o NIST elaborou um estudo para estimar o custo anual

provocado por falhas de software. O estudo foi intitulado "The Economic Impacts of

Inadequate Infrastructure for Software Testing", ou em português, "O Impacto Econômico

da Infraestrutura Inadequada para Testes de Software".

O impacto das falhas de software é alto devido ao fato de muitos empreendimentos,

desde indústrias à medicina, dependerem de software. Segundo estimativas desse

estudo, as falhas de software são predominantes e prejudiciais ao ponto de custar à

economia americana $59,5 bilhões de dólares anualmente. Os autores estimaram

também que pouco mais de um terço desse valor ($22,2 bilhões) poderiam ser eliminados

com a implantação de processos de testes que permitissem identificar (e

consequentemente corrigir) mais cedo e de maneira mais efetiva os defeitos de software.

Algumas falhas de software podem causar prejuízos imensos. Vamos ver agora alguns

exemplos de falhas de software que viraram notícias.

Erros em escalas da GOL:

Veja a seguir parte da notícia publicada no portal Terra

(http://noticias.terra.com.br/brasil/noticias/0,,OI4602632-EI306,00-

Gol+diz+a+Anac+que+falha+em+software+causou+erro+em+escala.html) sobre o

transtorno provocado por uma falha de software:


24

"Gol diz à Anac que falha em software causou erro em escalas”

A Agência Nacional de Aviação Civil (Anac)

informou nesta terça-feira que a companhia aérea

Gol disse que um problema no software para

planejamento de escala da tripulação gerou dados

incorretos que resultaram no "planejamento

inadequado da malha aérea e da jornada de

trabalho dos tripulantes". Hoje, a Gol foi convocada

pela agência a apresentar um plano de ação para

atender os passageiros de voos cancelados ou atrasados. A companhia operava cerca de

70% dos voos atrasados ontem em todo o País.

De acordo com a Anac, a Gol afirmou que o problema no sistema aconteceu em julho,

durante um upgrade no programa. "Por essa razão, foi adotada novamente a configuração

de escala do mês anterior", disse a agência, em nota: “O sistema era utilizado há três

meses, segundo a companhia, e com o conhecimento da Anac”.

Autodestruição do Foguete Ariane 501

Em junho de 1996, aproximadamente 37 segundos após o seu lançamento o foguete

Ariane 501 explodiu em voo.

O foguete possuía um sistema referencial inercial (SRI) para medir a trajetória. O SRI 2

era o principal, sendo que o SRI 1 funcionava como sistema redundante para assumir em

caso de falhas no primeiro. Ao invés de enviar os dados corretos da altitude, o SRI 2

enviou um código de erro decorrente de uma falha no software. Só que o SRI 1 não pode

entrar em operação, visto que 72 milissegundos antes apresentou o mesmo problema que

o SRI 2.

A falha foi provocada pela conversão de um float de 64 bits para um número inteiro com

sinal de 16 bits, referente à velocidade horizontal para a plataforma. Na tentativa da

conversão, foi gerado um número maior do que o comportado nos 16 bits. O motivo dessa

conversão estar vulnerável não foi identificada, uma vez que nenhum comentário no


25

código fonte justificava esse fato, sendo que existiam outras conversões com a proteção

adequada.

O foguete e a carga destruída estavam avaliados em $ 500 milhões de dólares.

Destruição da sonda da NASA Mars Climate Orbiter

A NASA enviou uma sonda para Marte para poder estudar o clima deste planeta. A sonda

Mars Climate Orbiter deveria entrar na órbita do planeta ao atingir uma altitude

aproximada de 150 km. Porém, devido a um erro de conversão de medidas, a sonda

entrou em uma altitude inferior, provocando a sua destruição. A conversão que não foi

realizada era de medidas inglesas para o sistema métrico.

O veículo espacial foi lançado no dia 11 de dezembro de 1998 e seu último sinal foi

recebido em 23 de setembro de 1999.

Os exemplos de incidentes apresentados nesta unidade apresentam alguns prejuízos

financeiros, e de tempo, ocasionados por falhas de software. Existem outras falhas

conhecidas que infelizmente além das perdas financeiras, provocaram a perda de vidas,

como por exemplo, o caso do Therac-25; um acelerador médico utilizado para tratar

tumores.

Com uma breve pesquisa na Internet é possível achar várias outras falhas de software

que ficaram famosas.

É possível inclusive assistir o vídeo de destruição do foguete Ariane 5. Um dos

endereços disponíveis é: http://www.youtube.com/watch?v=gp_D8r-2hwk


26

Você já presenciou algum prejuízo provocado por uma falha de software? Qual

(cuidado para não descrever detalhes confidenciais)? Ele poderia ter sido evitado com

a realização adequada dos testes? Como?


27

UNIDADE 6

Objetivo: Entender a importância do teste ser abordado como um processo e não como uma atividade

O Processo de Teste

É comum em projetos de software encontrar os testes sendo tratados como uma atividade

dentro do processo de desenvolvimento. Nessa abordagem, muitas vezes os testes são

iniciados após a etapa de desenvolvimento. A figura abaixo ilustra esse caso.

Figura 4 – Abordagem de Testes como uma Atividade no Processo de Desenvolvimento

Entretanto, para aumentar a qualidade do projeto, os testes precisam ter um processo

próprio não sendo mais tratado apenas como uma atividade dentro do processo de

desenvolvimento, conforme apresenta a figura abaixo.


28

Figura 5 – Abordagem de Testes com um Processo Próprio

Essa abordagem é importante para dar uma ênfase maior aos testes. Assim, o teste

passa a ter as etapas estruturadas possuindo atividades, artefatos, métodos, papéis e

responsabilidades. Esse processo deve ser iniciado em paralelo com o início do projeto

de software e, normalmente, deve ser realizados dentro do prazo do processo de

desenvolvimento, ou seja, de forma geral o cronograma do projeto não será aumentado

para realização dos testes.

Mesmo sendo um processo e não mais uma atividade, o processo de teste e o de

desenvolvimento estão interligados (conforme demonstrado a seguir no "Modelo em V"),

mas possuem alguns indicadores distintos. Tome como exemplo o indicador "Defeitos

Encontrados": quanto maior o número de defeitos encontrados, mais bem sucedido

considera-se os testes, e menos o processo de desenvolvimento.

Um processo é constituído por um conjunto de tarefas e atividades, sendo que algumas

podem ser sequenciais enquanto outras são realizadas em paralelo. De forma geral, as

principais atividades do processo de teste são: planejamento, preparação, especificação,

execução e entrega/avaliação (Rios et al.,2007).


29

O Modelo V

A representação gráfica que é mais utilizada para demonstrar a integração entre o

desenvolvimento e os testes é o Modelo V. Existem algumas variações do Modelo V, mas

de forma geral ele é representado conforme figura abaixo.

Figura 6 – Forma usual de representar o Modelo V

Outras formas de representação do modelo V diferentes da figura anterior existem. O

próprio Syllabus (documentação) da certificação de testes ISTQB, cita o modelo V sem

apresentar nenhuma figura e nem mesmo informar os nomes das quatro etapas de

desenvolvimento.

Alguns autores criticam esse modelo, como por exemplo, James Christie. Christie alega

que existem tantas variações do modelo em V que na prática podem significar qualquer

coisa. As representações normalmente compartilham o formato de "V" com uma seta

ligando os estágios equivalentes em cada lado.

Mas qual é o significado dessas setas?

1. O teste das entregas de cada etapa do desenvolvimento?

2. O planejamento dos testes em paralelo a cada etapa do desenvolvimento?


30

Seguem abaixo algumas críticas dos equívocos que podem ser ocasionados por conta da

interpretação do modelo V baseados em (Christie, 2008), e aproveitando o "gancho" das

críticas, algumas recomendações de boas práticas de testes (que na verdade

independem do modelo adotado).

1. Desencoraja a participação do usuário avaliando as funcionalidades e interface

antes da etapa de "Teste de Aceitação", que de acordo com a representação

ocorre mais tardiamente no projeto.

a. Recomendação: Idealmente, a prototipação e testes “cedo” devem ser

incluídos para identificar problemas quando são mais baratos de resolver.

Não é raro encontrar projetos que são submetidos para o cliente aprovar

somente ao final e o cliente não aprova o que foi entregue, gerando um

imenso prejuízo (para ambas as partes) e insatisfação. Portanto o

planejamento do projeto deve contemplar os testes de aceitação em todas

as etapas, submetendo sempre que possível às telas (mesmo que

protótipos) e funcionalidades para aprovação do cliente.

2. Caso ocorra o atraso no tempo do desenvolvimento, sobrará pouco tempo para

realização dos testes, visto que a interpretação pode deixar a entender que os

testes são realizados após o desenvolvimento.

a. Recomendação: É importante que os testes ocorram em paralelo durante

todo o processo


31

3. Começar as respectivas revisões e testes, em paralelo com as etapas de

desenvolvimento, não deve significar revisão e aceite ao final de cada etapa.

a. Recomendação: Revisões e testes devem ser realizados enquanto os

documentos/diagramas são elaborados. Testadores devem se envolver na

revisão de documentos o mais cedo possível ao longo do ciclo de

desenvolvimento.

Independente da representação gráfica utilizada é importante visualizar que o processo

de desenvolvimento e o de testes andam juntos para proporcionar um aumento na

qualidade do projeto do software.

Como os testes são realizados na empresa que você trabalha? Existe algum tipo de abordagem sistemática (casos de teste, apoio por ferramentas, automatização de testes, definição de papéis e processo, etc.)? Quais?


32

UNIDADE 7

Objetivo: Apresentar os fatores envolvidos em um bom planejamento de testes

Planejamento dos Testes

Para elaborar um planejamento de testes, é importante identificar as seguintes questões,

conforme aponta McGregor e Sykes (2001):

• Quem deve realizar os testes?

• Quais partes deverão ser testadas e receber mais atenção?

• Em qual momento os testes serão realizados?

• Como os testes serão realizados?

• Quanto de teste é adequado?

O planejamento dos testes visa minimizar os riscos e evitar desperdícios de tempo e

dinheiro. Se os testes forem realizados ao acaso, o esforço gasto tende a ser um prejuízo

e não proporcionar um retorno do investimento, visto que muitos defeitos não serão

identificados antes do software ir para produção.

E como em qualquer planejamento, o planejamento de testes após ter sido realizado no

início deve ser revisado e atualizado até o término do projeto, para não ficar engessado e

desatualizado, permitindo corrigir o rumo na ocorrência de imprevistos. Se o planejamento

do desenvolvimento mudar, o planejamento de testes tem que ser reavaliado.

Esse planejamento é feito em um documento de "Plano de Testes" que essencialmente

deve conter: o escopo, o processo de teste definido, os profissionais, ferramentas,

ambiente/hardware, estimativas financeiras, cronograma e riscos. Esses são itens

importantes, mas a composição do documento varia de empresa para empresa, sendo um


33

fator limitante os recursos disponíveis principalmente de tempo e dinheiro. Um exemplo

de modelo de plano de testes é o padrão IEE 829.

Os autores do livro referência para a certificação brasileira CBTS citam que o Plano de

Testes deveria seguir o modelo de Plano de Projeto do PMBOK, que é o conjunto de

práticas para gestão de projetos, publicado pelo PMI (a principal associação mundial de

gerenciamento de projetos). Eles identificaram que é possível fazer uma relação entre os

dois modelos.

De forma geral, um bom Plano de Testes abordará questões como: o que será testado, as

funcionalidades que serão testadas e as que não serão testadas em conjunto com o

motivo, o processo com as principais técnicas e ferramentas que serão utilizadas, os

critérios para considerar os testes concluídos, os artefatos que serão produzidos pelo

processo de testes (casos de testes, relatórios, etc.), indicadores de qualidade

(elaborados em conjunto com o cliente), a necessidade de aquisição de suprimentos

como hardware e software, necessidade de treinamento da equipe, as responsabilidades,

riscos do projeto de teste (ex: risco de determinado profissional ficar ausente, ou de ter

que utilizar uma ferramenta nova que ninguém tem experiência), risco do negócio e das

funcionalidades do software, custo e cronograma previstos.

Abordando esses itens, o planejamento visa proporcionar ações preventivas ao invés de

reativas, de forma que os riscos sejam minimizados e as medidas (como por exemplo,

compra de hardware/software) sejam realizadas no momento certo para evitar atrasos.

Análise dos Riscos

O planejamento está fortemente relacionado com a avaliação dos riscos que é

fundamental para definir o que será testado e em qual momento os testes podem ser

considerados terminados. Esse ponto é bem importante porque não tem como realizar

testes exaustivos para garantir que o sistema está livre de defeitos então é preciso

garantir que as partes mais críticas do sistema foram testadas.

São avaliados os riscos, ou seja, potenciais situações que se acontecerem podem gerar

diversos tipos de prejuízos e perdas para a organização. Dessa forma, as ameaças e


34

vulnerabilidades são analisadas para identificar potenciais formas de controle que podem

prevenir, ou minimizar os prejuízos.

A análise do risco avalia a probabilidade de ocorrência com gravidade do impacto do dano

causado. Essa análise deve ser feita ao longo de todo o projeto, uma vez que a gravidade

e o impacto podem mudar com o decorrer do tempo. Por exemplo, no início do projeto a

probabilidade de invasão ao software quando estiver pronto pode ser alto, mas no

decorrer do desenvolvimento o surgimento de um componente de segurança que pode

ser acoplado ao software diminui os riscos.

A avaliação deve contemplar tanto os riscos referentes ao projeto e processo de teste em

si, quanto os riscos inerentes ao negócio, como por exemplo, as funcionalidades que

contemplam áreas mais críticas.

Quanto ao projeto de teste os riscos já começam no orçamento e no cronograma. Se a

verba e/ou o tempo disponível para os testes forem poucos, os testes serão realizados

inadequadamente, aumentando muito a probabilidade dos defeitos serem encontrados no

software já implantado, potencializando assim os prejuízos. Muitas vezes, a empresa que

está orçando o desenvolvimento do software não contempla na proposta comercial o

custo e tempo para os testes, percebendo que tomou prejuízo somente no momento dos

testes de aceitação quando o cliente não aprova o que lhe foi apresentado. Portanto, no

fechamento do contrato é fundamental negociar prazos e custos adequados que

contemplem a realização dos testes. Outros riscos envolvem a qualificação da equipe,

utilização de uma ferramenta nova para realização dos testes, ambiente de teste pouco

parecido com o ambiente de produção, inadequação de metodologias, processo e

controle dos artefatos de teste.

A realização dos testes custa dinheiro e o investimento necessário aumenta na medida

em que a cobertura dos testes aumenta. A análise de riscos bem realizada proporciona

uma destinação coerente dos esforços, priorizando as partes que apresentam maior

probabilidade de ocorrência x impacto de perda (risco) de forma que o teste tenha o maior

nível possível de confiabilidade no tempo disponível (Rios et al., 2007).


35

Portanto, é necessário realizar uma análise de custo x benefício para avaliar até que

ponto vale a pena investir em testes, respondendo perguntas como: "O custo da

ocorrência do defeito é muito maior do que o custo da sua prevenção?".

Uma forma de se estabelecer a prioridade é definir quantitativamente a probabilidade e

severidade (impacto) da ocorrência. A tabela a seguir apresenta um exemplo simples de

análise quantitativa de risco utilizando escalas como 1, 5, 10, 15; sendo que quanto maior

o número maior a prioridade.

Funcionalidade Probabilidade Severidade

(Impacto)

Prioridade

(P.x S.)

Realizar Depósito em Conta 15 15 225

Encerrar Conta 5 10 50

Cadastrar Fornecedor 1 1 1

Tabela 2– Exemplo simples de cálculo de prioridade de funcionalidade a ser testada

Algumas das formas de determinar o risco são: intuição baseada na experiência de

profissionais, consenso da equipe e estimativas. Essa última se baseia em dados para o

cálculo, como por exemplo: "Quanto custa cada hora que essa máquina fica parada sem

produzir?", "Quanto se perderá, por minuto, se o site ficar fora do ar?".

Adicionalmente, pode-se utilizar também o Princípio de Pareto adaptado, em que 20% do

software são responsáveis por 80% das funcionalidades mais utilizadas. Para determinar

quais são essas funcionalidades mais utilizadas, se o software já estiver em produção

(vale lembrar que as manutenções também devem ser testadas), pode-se monitorar as

estatísticas de uso, e caso o software não esteja implantado, perguntar aos usuários.

Porém, é importante perceber que o Princípio de Pareto, por si só, pode não ser

suficiente, visto que uma funcionalidade pode ser muito importante e raramente utilizada,

mas se falhar pode causar um grande prejuízo. Portanto, deve-se avaliar quando essa

informação será útil, atrelada a outras estimativas.


36

Término dos Testes

Um ponto muito importante relacionado ao projeto de testes é o momento de identificar o

seu fim, para não acontecer: testes de menos, com uma interrupção, muito antes de

atingir a cobertura adequada (essa situação é mais comum, principalmente por causa das

pressões por prazos, ou inadequação em definir a cobertura apropriada); ou testes de

mais, implicando em custos, acima do necessário, com o excesso de testes, pois o custo

adicional, com os testes, não compensa o custo que seria provocado pela falha.

Figura 7 – Custo do teste comparado com número de defeitos que faltam ser corrigidos (Rios et al.,2007)

Portanto, é importante identificar o ponto de equilíbrio. Esse ponto de equilíbrio está

relacionando com aspectos de criticidade: quanto mais crítico o negócio, mais testes

devem ser realizados. Por exemplo, os testes de um software para controle de rota de

espaçonaves é muito mais crítico do que um software para gestão financeira pessoal, de

forma que o primeiro requer muito mais testes, visto que, o prejuízo ocasionado por uma

possível falha pode ser muito alto.


37

Mas como se pode identificar esse ponto de interrupção? Rios e colaboradores (2007)

apontam algumas sugestões que podem ser utilizadas em conjunto para definir o

momento de término:

• Quando intervalo de ocorrência e identificação de defeitos aumenta muito – de

horas para dias;

• Quando a nova realização de um ciclo de teste acha menos do que um número

determinado de "bugs";

• Quando atinge determinado valor de cobertura sem descobrir novos defeitos;

• De acordo com o número de defeitos encontrados e ainda não corrigidos,

considerando a respectiva severidade (ex: "existem defeitos, de alto ou médio

risco, que ainda não foram corrigidos?").


38

UNIDADE 8

Objetivo: Entender os aspectos envolvidos com a preparação do ambiente de teste

Ambiente de Testes

É preciso planejar também o ambiente em que os testes devem ser realizados. Engana-

se quem pensa que o ambiente se refere apenas ao hardware necessário; ele engloba

toda a estrutura envolvida com a execução dos testes, como por exemplo: sistemas

operacionais, browsers compatíveis, a massa de dados a ser utilizada, e assim por diante.

As características do ambiente vão depender de alguns fatores. Quanto mais crítico o

software, mais o ambiente de teste deve ser parecido com o ambiente de produção. E em

alguns casos, o ambiente de produção pode ser o mais variado possível. Por exemplo,

um grande site de vendas precisa rodar perfeitamente em diferentes browsers (e em

diferentes versões do mesmo) combinados com diferentes sistemas operacionais. Se uma

atualização do site não rodar em um determinado browser padrão, o prejuízo pode ser

grande; visto que seus clientes em um segundo podem acessar o site do concorrente.

Assim, a preparação do ambiente deve levar em consideração as características de cada

projeto. Um software com arquitetura cliente-servidor deve permitir a realização adequada

de testes em ambientes que simulem bem a parte do cliente e também em ambientes que

simulem a parte do servidor.

Um software que precise ser testado com diferentes sistemas operacionais e

configurações; pode utilizar as máquinas virtuais (ou "Virtual Machines"). Um mesmo

computador pode ser utilizado com diferentes máquinas virtuais. Cada máquina virtual

pode receber um sistema operacional diferente, reduzindo os custos. Assim, um único

computador com um Windows 7 (ou qualquer outro sistema operacional) instalado, pode

ter uma máquina virtual com o Linux Ubuntu 10.10, outra com o Windows XP, outra com

Mac O.S, etc. A referência do CBTS lembra um ponto importante; normalmente esses

ambientes não são recomendados para teste de performance, uma vez que a máquina


39

virtual pode não ter a quantidade suficiente de recursos alocados (ex: memória e

processamento) por estar sendo compartilhada com o sistema operacional do

computador.

Existem casos em que determinadas condições são proibitivas para a reprodução do

ambiente no local do desenvolvimento. Pode-se citar como exemplo fictício, mas provável,

uma indústria que contrata uma empresa para desenvolver um software. Essa indústria

pode ter uma estrutura de hardware muito cara que pode custar muito mais do que o

software que está sendo desenvolvido. Nesse caso, a empresa desenvolvedora tem que

realizar alguns tipos de testes no ambiente de testes da indústria, enviando alguns

participantes de sua equipe para lá. É importante perceber, que essa situação deve ser

prevista no planejamento dos testes.

Massa de Dados

A necessidade dos dados que serão utilizados nos testes varia de acordo com a

necessidade de cada tipo de teste. Os testes de unidades e integração normalmente não

precisam de muitos dados, enquanto os testes de performance precisam, e para os testes

de homologação e aceitação é interessante que tenha uma quantidade representativa.

Em alguns casos, ter dados reais de uma base já em produção é relevante. Mas nem

sempre é possível obtê-los seja porque não existe uma base de dados de produção

(sistema novo) ou porque a política de privacidade da empresa contratante não permite

que esses dados sejam acessados por terceiros. Caso seja possível obter os dados reais

é importante ter cuidado para camuflar dados confidenciais, substituindo-os ou

convertendo-os no momento da importação. Também é preciso, avaliar se é necessário

utilizar todos os dados, ou se apenas uma parte deles seria mais adequada, filtrando o

que for relevante para reduzir a base. Em alguns casos, como nos testes de performance

e estresse, os dados geralmente não precisam ser reais, ou seja, em muitos casos podem

ser gerados aleatoriamente.

Outro ponto importante a se observar, na realização de testes com dados reais, é em

relação ao disparo de e-mails. Se a aplicação possui funcionalidades que disparam e-

mails, na base de teste é fundamental adotar uma política que tratem os mesmo,


40

adotando medidas como substituir os e-mails originais por e-mails de teste, por exemplo.

Essa política visa evitar problemas maiores com as pessoas cadastradas no sistema.

Além de ser incômodo para pessoa receber e-mails desse tipo, uma informação falsa

pode ser enviada causando confusão e problema. Por exemplo, se estiver sendo

realizado um teste em um sistema bancário e um cliente que possua uma fortuna recebe

um e-mail disparado pelo ambiente de testes informando que sua conta foi zerada,

certamente seria gerado um transtorno. Outro ponto que deve ser observado, é que a

aplicação no ambiente de testes deve estar apontando para um banco de dados de

testes, pois em alguns casos, por descuido, eles podem estar apontando para o banco de

produção, ocasionando a perda de dados importantes.

Quando não for possível, ou não for necessário obter dados reais, de acordo com o

objetivo e necessidade de volume dos testes, os mesmos podem ser gerados

manualmente ou então automaticamente; sendo gerado de forma aleatória por alguma

ferramenta.

Como diferentes tipos de testes demandam de diferentes tipos de dados, várias bases

com propósitos distintos são criadas. Após essa criação, é interessante fazer o backup

dessas bases, armazenando-os de forma adequada e categorizada, para futura

reutilização em testes de regressão ou outros. Por exemplo, suponha um sistema que

gerencia planos de saúde que de acordo com a idade do cliente cadastrado o valor e os

benefícios mudam. Os casos de testes vão ser elaborados para exercitar essa situação

de forma que um determinado cliente seja "envelhecido" nos testes, passando por

diferentes idades. Assim, um teste pode começar com "João da Silva" com 5 anos de

idade e no final dos testes, ele estar com 75 anos. Após a realização de alterações no

sistema os testes de regressão vão precisar que "João da Silva" tenha 5 anos novamente,

bastando para isso restaurar a base previamente criada com essas condições.

Ferramentas

Faz parte de preparação, e utilização do ambiente, o uso de ferramentas. As ferramentas

visam apoiar diversos aspectos relacionados aos testes, desde a gestão do processo de

teste em si até a execução dos mesmos. Portanto, existem ferramentas para gerenciar os


41

testes, controle de defeitos, cobertura de código e ainda, realizar testes de estresse,

facilitar os testes unitários, comparar os resultados dos testes, dentre outros. Existem

ferramentas que atuam sobre uma atividade específica enquanto outras contemplam mais

do que uma.

Apenas a aquisição da ferramenta não é condição suficiente para obter o sucesso na

atividade que ela suporta. Portanto, existem os benefícios que podem ser conquistados e

também existem os riscos que são apresentados abaixo, baseados na referência da

certificação do ISTQB:

• Alguns possíveis benefícios:

o Redução de trabalhos repetitivos (ex: execução de testes de regressão)

o Avaliação dos objetivos (ex: número de defeitos, cobertura de código)

o Maior consistência e possibilidade de repetições (ex: testes realizados por

uma ferramenta)

o Facilidade de acessar as informações sobre os testes (ex: estatísticas e

gráficos referentes ao progresso do teste, como número de defeitos graves

que faltam ser corrigidos)

• Alguns riscos potenciais:

o Criar expectativas falsas sobre a ferramenta, como por exemplo,

funcionalidades oferecidas e facilidade de uso;

o Subestimar o tempo necessário para iniciar o uso da ferramenta, assim

como, custo e esforço necessário para conseguir utilizar a mesma;

o Subestimar o esforço necessário para manter atualizados os artefatos

gerados pelas ferramentas;

o Tentar utilizar a ferramenta para tudo, mesmo quando a realização manual

seria mais adequada.

Ao longo deste Módulo, serão apresentadas algumas ferramentas gratuitas, que se forem

bem empregadas podem auxiliar bastante nos testes. Essas ferramentas servem para

demonstrar conceitos para você saber escolher qual tipo de ferramenta será adequada ao


42

seu projeto. Entretanto, o Módulo não tem a pretensão de abranger todos os aspectos

dessas ferramentas, até mesmo porque o manual delas é extenso. Assim, problemas com

instalação e utilização das ferramentas não devem ser retiradas na sala de aula, e sim

nos manuais encontrados em fóruns de discussão da internet, dentre outros meios

adequadamente disponíveis na web para essa finalidade.

Algumas ferramentas demonstradas são específicas para linguagem de programação

Java. Uma vez entendido os benefícios oferecidos por determinado tipo de ferramenta,

independente da linguagem de programação, basta pesquisar na internet por uma

ferramenta similar para a sua linguagem de programação preferida.

Existem ferramentas que facilitam a geração, extração e manipulação de dados, como por exemplo a ferramenta gratuira Kettle da suite Pentaho, disponível em http://kettle.pentaho.com/.

Para crirar as "Virtual Machines" uma opção gratuita é o Virtual Box - http://www.virtualbox.org/.


43

UNIDADE 9

Objetivo: Apresentar as abordagens para montar a equipe de testes, bem como os papéis existentes

A Equipe e os Papéis nos Testes

Conforme visto anteriormente, as atividades relacionadas com os testes devem ser

iniciadas junto com projeto de software. Dessa forma, a equipe de testes inicia sua

participação no início do projeto para detectar defeitos o mais cedo possível, visando

evitar a propagação dos mesmos e tentar corrigi-los enquanto os custos são menores.

A equipe de testes utilizará os artefatos gerados pela equipe de desenvolvimento para

testá-los ou planejar testes de outros artefatos.

Para montar a equipe de testes, existem algumas abordagens que vão desde utilizar os

próprios desenvolvedores até terceirizar os testes para equipe externa. A estratégia

utilizada depende muito das condições do projeto, como custo, prazo, dentre outros. O

ideal é uma equipe de testes dedicada (seja ela interna ou terceirizada), mas muitas

vezes esse objetivo é difícil de alcançar por restrições financeiras. Mas é importante ter

em mente que: dificilmente se obtém resultados satisfatórios quando o desenvolvedor

testa o próprio código. Alguns motivos são:

• O testador precisa trabalhar de maneira isenta e independente e os seres humanos

tendem (mesmo que de forma inconsciente) a encobrir os seus próprios enganos.

• É difícil ter motivação psicológica para elaborar casos de testes que mostram que

seu código possui defeitos

• Ao desenvolver utilizou-se uma lógica de raciocínio que precisa ser modificada,

para tentar identificar os possíveis defeitos.


44

• O desenvolvedor possui uma lista de atividades para desenvolver e normalmente

fica ansioso. Quando termina uma atividade, tem a intenção de logo começar outra

e não parar e ficar testando o que já fez.

Essas dificuldades não são exclusivas de desenvolvedores de software, por isso, estão

presentes em qualquer tipo de construção intelectual. Você já tentou revisar um texto

depois que escreveu? E revisar novamente após outra pessoa ter feito uma revisão

seguida de correções? Muitas pessoas consideram essa atividade torturante.

Abordagens para montar a equipe

A seguir, algumas vantagens e desvantagens de montar a equipe de testes com os

desenvolvedores e outra com profissionais designados somente para essa função, com

base na referência da certificação CBTS (Rios et al., 2007).

1. Alocar equipe de desenvolvimento para realizar os testes

Nesse caso, um desenvolvedor (ou analista) deve testar a funcionalidade do outro, de

forma que o responsável nunca deve testar o que ele mesmo produziu (com exceção dos

testes unitários e alguns tipos de integração).

Para isso, é importante que os desenvolvedores passem por treinamentos que permitam

desempenhar melhor a função de testador, adquirindo conhecimentos com técnicas,

documentos e ferramentas de testes.

Apesar dessa abordagem envolver menores investimentos iniciais e permitir alcançar

resultados positivos, o gerenciamento passa ser mais trabalhoso, uma vez que é

necessário organizar o tempo e sincronizar cronogramas de forma a não atrapalhar o

trabalho do outro desenvolvedor (seja por interrupção ou espera da realização dos testes

para poder prosseguir).

Além da dificuldade de sincronizar cronogramas, outros riscos envolvidos são: os

desenvolvedores terão uma tendência a realizar os testes de maneira mais informal.

Assim, dificilmente manterão os documentos de testes atualizados, portanto, não terão

conhecimento a respeito do negócio.


45

2. Alocar equipe independente para realizar os testes

A equipe independente pode ser da própria empresa desenvolvedora ou então uma

equipe externa, terceirizada. Essa abordagem tem um custo inicial maior, visto que mais

pessoas estarão envolvidas e alocadas no projeto. Porém, tende a proporcionar um

retorno financeiro maior ao longo do tempo, principalmente se for contabilizado o custo de

corrigir os defeitos encontrados no software em produção.

A qualidade final é maior devido à: dedicação de tempo maior, conhecimento mais

especializado nas técnicas, ferramentas e metodologias de teste.

Para funcionar bem, é preciso gerenciar alguns pontos, como por exemplo: a equipe de

desenvolvimento pode achar que a responsabilidade sobre a qualidade é somente da

equipe de testes, diminuindo o seu padrão de qualidade e existe uma tendência de

desentendimento entre as duas equipes, que pode ser ocasionado principalmente se os

testadores reportarem os erros com linguagem inapropriada (ex: deboche, agressividade,

etc.).

Beizer já dizia, em 1990: "Testadores, quebrem o software como é de sua

responsabilidade, e teste com força, mas não sinta prazer com a dor do programador"

(tradução livre).

Papéis no Processo de Teste

A equipe de desenvolvimento é responsável por realizar os testes unitários e de

integração. Em relação à equipe de testes, normalmente os papéis existentes são:

• Gerente de Teste: esse papel é semelhante ao gerente de projetos, e normalmente

é encontrado apenas em equipes maiores.

• Líder do Projeto de Teste: lidera um projeto de teste específico

• Arquiteto de Teste: tem como responsabilidade preparar o ambiente de testes e

escolher as ferramentas que serão utilizadas

• Analista de Teste: elabora os casos de teste


46

• Testador: executa os casos de teste

Pode ser que profissionais acumulem alguns papéis (tanto de teste como de

desenvolvimento), de acordo com a necessidade e porte da equipe e projeto. Em relação

à automatização dos testes e aos testes de performance, essa atribuição, dependendo da

equipe, fica sob responsabilidade do testador ou do analista de teste.

Certificações para Profissionais de Testes

Existem no mercado várias certificações para os profissionais de testes. Abaixo são

relacionadas três delas (2 delas já citadas neste módulo) que são bem aceitas no Brasil,

juntamente com algumas informações adicionais. Vale ressaltar que essas informações

servem apenas para dar uma pequena noção, visto que os valores, tempo, número de

questões podem mudar.

• CBTS - Certificação Brasileira de Teste de Software

o ALATS (Associação Latino-Americana de Teste de Software)

o Material de apoio para a certificação: Livro Base de Conhecimento em Teste de Software, 2ª edição.

o Valor: R$ 300 reais.

o Número de Questões: 100 questões.

o Percentual de Acerto para aprovação: 75%

o Duração: 3 horas.

o Formato: Múltipla escolha.

o Site: http://www.alats.org.br

• CTFL Foundation - Certified Tester, Foundation Level

o ISTQB(International Software Testing Qualifications Board)

o Material de apoio para a certificação: "Foundation Level Syllabus" e "Glossary of Terms" (ambos possuem tradução para português).

o Valor: R$ 350 reais.

o Número de Questões: 40 questões.


47


o Duração: 1 hora.

o Formato: Múltipla escolha.

o Site: http://www.bstqb.org.br/

• CSTE - Certified Software Tester

o QAI - Quality Assurance Institute

o Material de apoio para a certificação: Common Body of Knowledge(CBOK).

o Valor: U$ 350 dólares.

o Número de Questões: 100 múltipla-escolha e 20 dissertativas curtas


o Duração: 4 horas e meia.

o Formato: Múltipla escolha e dissertativa.

o Site: http://www.softwarecertifications.org/qai_cste.htm

Uma alternativa de terceirização da equipe de testes que vem ganhando popularidade, principalmente no exterior é o "CrowdTest" (algo como"teste da multidão").

Tarefa Dissertativa

Acesse a sua sala de aula para realizar a seguinte tarefa dissertativa:

Pesquise em artigos e sites e faça uma síntese, com suas próprias palavras, sobre "CrowdTest".


48

UNIDADE 10

Objetivo: Entender a importância de realizar revisões e inspeções nos artefatos do processo de desenvolvimento

Técnicas Estáticas - Revisão e Inspeção

As técnicas de Teste Dinâmico necessitam da execução do código fonte para serem

realizadas. Portanto pode-se citar como exemplo, a execução dos testes unitários e dos

testes de performance como técnicas de Teste Dinâmico.

Já as técnicas de Teste Estático não estão relacionadas à execução do código fonte, que

pode muitas vezes nem existir ainda. São exemplos de testes estáticos, as revisões de

artefatos como especificação de requisitos, diagrama de classes, inspeção do código

fonte, dentre outros. Portanto, muitas das técnicas de Teste Estático são realizadas

"manualmente", como a leitura de documentos para identificar inconsistências.

Como estudado anteriormente, quanto mais cedo um defeito for identificado, menor é o

custo da sua correção. Para evitar que defeitos introduzidos nos artefatos, como

especificação de requisitos, diagramas de classe, etc., se propaguem para os demais

artefatos, é importante realizar a revisão desses documentos.

Para facilitar a leitura, os defeitos dos artefatos citados nesta Unidade, são mais

abrangentes do que o conceito de defeito que será estudado, abstraindo o conceito para

qualquer tipo de problema. Ao revisar os requisitos e diagramas os tipos de problema

procurados são (Kalinowski,2008):

• Omissão: falta de informações relevantes a respeito do sistema, como por

exemplo, parte importante não definida, ausência de classes, diagramas, etc.

• Ambiguidade: a descrição do texto ou diagramas permite que a mesma informação

seja interpretada de diferentes formas


49

• Inconsistência: informações no mesmo artefato ou em artefatos distintos são

conflitantes entre si

• Fato Incorreto: a informação textual ou diagramática não condiz com a verdade

• Informação Estranha: informações que não são necessárias ou não são utilizadas

• Outros: os demais tipos de defeito, como posicionamento errado de informações

em determinada seção.

A realização da revisão deve iniciar o quanto antes e não somente ao término de uma

fase. As revisões podem seguir processos informais ou formais. Segundo o Syllabus do

ISTQB, a revisão formal normalmente contempla as etapas de planejamento, kick-off,

preparação individual, reunião de revisão, correção e acompanhamento. No planejamento

são definidas as técnicas a serem empregadas e os revisores, dentre outros. A fase de

kick-off contempla a distribuição dos documentos, e explicação para os participantes

sobre os objetivos, documentos e processos. A preparação individual consiste na revisão

individual antes da reunião, de forma que cada revisor identifique os problemas,

comentários e sugestões. Na reunião de revisão, os participantes discutem as anotações

realizadas previamente e decidem com a ajuda do moderador os defeitos (e os pontos

que não são defeitos) e possíveis encaminhamentos. O retrabalho (correção) é a etapa de

correção dos defeitos, normalmente pelo autor do artefato. O acompanhamento consiste

em verificar se os defeitos foram devidamente corrigidos e a necessidade de uma nova

revisão.

As abordagens para leitura normalmente são: ad hoc, baseadas em checklists e técnicas

de leitura de software. A leitura ad hoc não possui um método definido, sendo sua eficácia

dependente da habilidade do revisor. A leitura baseada em checklist (ou lista de

verificação) não apresenta uma metodologia sistemática, mas sim um conjunto de

características de defeitos conhecidos previamente, que devem ser verificados (Falbo,

2008). Já a técnica de leitura de software visa adotar uma postura mais sistemática na

realização da revisão. Pode-se citar como exemplo, a Técnica de Leitura Orientada a

Objetos (OORT - Object-Oriented Reading Techniques). A OORT estabelece

procedimentos para revisão de documentos e diagramas do projeto orientados a objeto


50

(Mafra e Travassos; 2005). Duas dimensões são analisadas, a leitura horizontal

(verificação de consistência de artefatos de uma mesma fase) e leitura vertical

(verificação de artefatos produzidos em fases diferentes) (Falbo, 2008). Assim, são

apresentadas técnicas que verificam, por exemplo, a consistência dos casos de uso com

o diagrama de classes.

Na inspeção do código fonte, algumas atividades podem ser apoiadas por ferramentas.

Por exemplo, a ferramenta Checkstyle (http://checkstyle.sourceforge.net/) verifica se o

código fonte dos desenvolvedores segue um padrão como nomenclatura de métodos,

código duplicado, etc. Já a ferramenta gratuita FindBugs (http://findbugs.sourceforge.net/),

para Java, analisa estaticamente o código fonte e aponta possíveis defeitos, baseados em

padrões conhecidos. Dentre as inúmeras análises realizadas, aponta variáveis que não

são inicializadas, possíveis ocorrências de exceções de "null pointer", indicação de

problemas de performance com código desnecessário, tratamento incorreto de exceções,

etc.


51

UNIDADE 11

Objetivo: Conhecer os conceitos e conteúdo dos casos de Teste

Casos de Teste

O Caso de Teste é um dos artefatos do processo de teste. Seu objetivo é documentar os

cenários de teste de forma a verificar se os resultados esperados estão sendo atingidos.

Normalmente, utiliza-se os casos de uso (do processo de desenvolvimento) para elaborar

os casos de teste, sendo que cada cenário do caso de uso pode ser coberto por um ou

mais casos de testes. Entretanto, existem alguns casos de testes que são baseados em

requisitos não funcionais, como por exemplo, desempenho, e dessa forma não utilizam os

casos de uso como base.

Como os casos de uso são utilizados como base, caso eles sejam alterados os casos de

teste precisam ser revisados. Por isso, é importante manter a rastreabilidade entre a

especificação de requisitos e casos de teste. Uma boa ferramenta de gestão de teste

deve oferecer a funcionalidade para realizar essa rastreabilidade.

Conteúdo do Caso de Teste

O conteúdo do caso de teste, normalmente, é composto por valores de entrada, pré-

condições de execução, os passos/procedimentos e resultados esperados. Essas

informações normalmente são utilizadas, mas o conteúdo do documento pode ser

adaptado pela equipe.

Segue abaixo uma possibilidade de campos para compor um caso de teste:

• Autor: autor do caso de teste

• Id: número que identifica o caso de teste

• Título: deve descrever brevemente o caso de teste


52

• Pré-condições: condição que deve ser atendida antes do teste ser executado. Por

exemplo, pode ser necessário ter um cliente cadastrado com um filho de 17 anos

• Dados de entrada: indica os dados que serão informados durante o teste

• Procedimentos: descreve os passos que devem ser realizados para executar o

teste, indicando qual passo é realizado pelo testador e qual é realizado pelo

sistema.

• Dados de saída: dados que foram modificados ou produzidos durante a execução

do teste.

• Pós-condições: situações que devem ser verificadas ao término do teste, como

mudanças de status e outras alterações ocasionadas pelo teste.

• Ambiente: utilizado para informar características do ambiente, como por exemplo,

uma versão do sistema operacional e do browser.

• Tipo de execução: se o teste deve ser executado manualmente ou

automaticamente

• Rastreabilidade: indica os artefatos do desenvolvimento (ex: o caso de uso,

requisito) que serviram como base para criação do caso de teste.

• Observações: informações adicionais que o analista de teste queira passar para o

testador

Esses campos podem ser modificados de acordo com a necessidade da equipe, que pode

querer, por exemplo, unificar os "dados de saída" e "pós-condições" que compõem os

resultados esperados. É importante ressaltar que os resultados esperados devem estar

presentes, caso contrário o testador pode julgar um resultado errado, mas aparentemente

correto como válido.

A seguir é apresentado um caso de teste elaborado a partir de um cenário de caso de uso

imaginário, de número RN025, que especifica um depósito em conta bancária,

determinando que os depósitos acima de R$ 14.999,99 devem enviar um e-mail para o

dono da conta.


53

<CT0125 - Realizar depósito de R$ 15.000,00> Autor João Gomes Pereira

Data 14/08/2011

Pré-condições O usuário deve possuir uma conta ativa e estar logado no sistema

Dados de entrada Usuário: André Leal, Conta: 123456, valor para depósito R$ 15.000,00

Procedimentos PA: O usuário informa que deseja depositar R$ 15.000 em sua conta PS: O sistema exibe uma mensagem de confirmação PA: O usuário confirma a operação PS: O sistema atualiza o saldo da conta, sendo esse = saldo inicial + R$ 15.000,00, e envia um e-mail para o endereço cadastrado do usuário

Dados de saída Saldo = saldo inicial + R$ 15.000,00

Pós- Condições 1 - O saldo da conta atualizado 2 -Um e-mail foi enviado para o endereço especificado no cadastro do usuário, informando a operação realizada e o novo saldo

Ambiente Sem restrições específicas

Tipo de Execução

(ex:Automática, Manual)

Manual

Rastreabilidade RN025

Observações Gerais N/A

Figura 8 – Exemplo de um caso de teste

O exemplo acima apresenta um caso de teste para o requisito RN025. Outros casos de

testes deveriam ser elaborados para o mesmo requisito, como depósito para conta

inativa, depósito de valor negativo, dentre outros. Supondo-se que o mesmo requisito

especificasse que depósitos acima de R$ 30.000,00 gerassem pontuação extra no

programa de fidelidade. Para realizar um teste com depósito de R$ 29.999,99 um novo

caso de teste teria que ser elaborado.

O caso de teste acima foi apresentado dessa forma, propositalmente, para mostrar que

para generalizar e reaproveitar o caso de teste; é importante que os valores possam ser

variáveis. Para generalizar, o nome do caso de teste deveria ser mudado, passando para

algo do tipo "Realizar depósito de valores que enviam e-mail, mas não geram pontuação

extra" e nos procedimentos e dados de saída, ao invés de colocar o valor fixo R$


54

15.000,00, o texto descreveria que seria um valor informado pelo usuário, de forma que

ficasse genérico o suficiente para permitir que os valores variassem nos "dados de

entrada". Esse conceito chama-se DDT (Data Driven Test, ou em português, Testes

Orientados a Dados) que serão abordados mais adiante.

Características e Potenciais Problemas

A referência para certificação CBTS apresenta algumas características, problemas e

recomendações interessantes a respeito dos casos de teste, que são apresentados a

seguir.

As características de qualidade de um caso de teste são:

• Efetivo: deve testar o que foi planejado

• Econômico: não deve possuir passos desnecessários

• Reutilizável: deve ser possível re-executar (muito importante para os testes de

regressão)

• Rastreável: identifique o requisito que está sendo testado

• Autoexplicativo: qualquer testador deve ser capaz de executar

A referência do CBTS apresenta também problemas que precisam ser controlados pelo

gerenciamento de testes durante todo o projeto.

• Mudança de Requisitos: É importante tentar identificar quais os requisitos que

apresentam os maiores riscos de mudança, e escrever primeiro os requisitos que

não serão impactados pela mudança. A revisão dos casos de testes produzidos

implica em tempo e custo. O gerente de projeto deve ter conhecimento desses

itens e definir a prioridade do que deve ser refeito, dando prioridade aos requisitos

de maior risco.

• Mudança de cronograma: Se o prazo para elaboração dos casos de teste for

reduzido por alguma razão, o gerente do projeto deve participar na escolha da

prioridade, de forma que os cenários de maior risco sejam elaborados antes. Só se


55

deve considerar aumentar a equipe se houver tempo suficiente para treinamento e

adaptação dos integrantes novos

• Rotatividade da equipe: Todo participante novo deve entender os objetivos,

cronograma e organização do projeto. Eles devem ter acesso à documentação do

software para conhecer primeiro as regras de negócios e só então elaborar os

casos de teste. É importante que um profissional mais experiente revise os

artefatos produzidos pelos novos integrantes.

Existem técnicas e critérios de testes que permitem otimizar a definição dos casos de testes.

Acesse sua sala de aula para ler um trecho do artigo "Introdução a Teste de Software", de Arilo Neto, publicado na primeira edição da Revista Engenharia de Software. O trecho selecionado e disponibilizado aborda os critérios: "Particionamento em Classes de Equivalência","Análise do Valor Limite" e "Grafo de Causa-Efeito"


56

UNIDADE 12

Objetivo: Conhecer os aspectos da execução dos testes, utilização de testes orientados à dados (DDT) e quando os testes devem ser automatizados.

Execução dos Testes

As informações a respeito da execução dos testes devem ser armazenadas por serem

preciosas para acompanhamento e tomada de decisão. A partir desse registro é possível

saber quantos testes foram realizados, quantos foram bem sucedidos, quantos falharam e

quantos não foram executados. Assim, consegue-se cruzar informações sobre os testes,

riscos e prioridades, obtendo informações do tipo "quantos testes de partes de alto risco

falharam". Uma boa ferramenta de gestão de testes deve permitir o cadastro dessas

informações, bem como emitir relatórios com esses indicadores citados.

Na execução, outra informação valiosa que deve ser registrada é a respeito dos defeitos

encontrados. Essa informação deverá ser salva em uma ferramenta de "Gestão de

Defeitos", que será tratada adiante.

Durante a execução, de acordo com os tipos de defeitos encontrados, é possível

identificar se o desenvolvedor liberou o código para teste antes do momento adequado.

Se muitos defeitos e/ou defeitos primários forem encontrados durante o teste (defeitos do

tipo que deveriam ser identificados nos testes unitários e de integração do desenvolvedor)

significa que o código foi liberado para o teste antes do tempo. Esse fato representa um

custo adicional, já que o testador vai testar funcionalidades que não estão

adequadamente finalizadas. Vai gastar tempo registrando esses defeitos que poderiam

ser identificados pelo desenvolvedor, e depois terá que realizar os mesmos testes,

novamente, para saber se foram corrigidos. Portanto, o cronograma para realização dos

testes poderá ser prejudicado, portanto o gerente de testes e de projeto devem tomar as

devidas providências.


57

Ainda durante a execução, o testador pode verificar que o resultado esperado do caso de

teste e o resultado obtido são diferentes. Se ele perceber que o software aparenta estar

correto, e achar que o erro está na especificação do caso de teste, ele deve reportar para

o analista de teste avaliar. Se o analista confirmar que o caso de teste está errado, ele o

corrigirá. Caso contrário, o testador deverá reportar ao defeito encontrado na ferramenta

de gestão de defeitos.

Testes Orientados a Dados (DDT - Data Driven Test)

O conceito de "Testes Orientados a Dados" (do inglês Data Driven Test - DDT) se refere a

executar (e também descrever) o mesmo teste, apenas variando os dados, permitindo

realizar vários testes sem ter que alterar o código (ou caso de teste). Para atingir esse

resultado, muitas vezes arquivos externos em csv, xml, dentre outros formatos, são

utilizados. Algumas ferramentas já oferecem suporte à utilização do DDT, mas em alguns

casos é preciso codificar.

A tabela abaixo demonstra um exemplo que poderia ser utilizado para testar se a

mensagem de boas vindas está sendo exibida corretamente para os usuários

cadastrados, de acordo com seu cargo.

Login Senha Mensagem Esperada

joao joao Usuário não cadastrado

jose jose Bem vindo desenvolvedor José

carlos carlos Bem vindo administrador Carlos

... ... ...

... ... ...

... ... ...

marta marta Bem vinda analista Marta

Tabela 3 – Exemplo de utilização de dados para DDT

Dessa forma, a ferramenta utilizaria os dados do login e senha como dados de entrada e

verificaria se a mensagem apresentada corresponde ao que era esperado. Se for preciso

testar para outros usuários, basta adicionar/alterar linhas na tabela e executar o teste

novamente.


58

Automatização dos Testes

A automatização dos testes permite executá-los novamente de forma muito mais fácil,

contribuindo para a realização dos testes de regressão, dando uma confiança muito maior

para a qualidade do software. Sendo assim, a automatização dos testes parece uma ideia

fantástica, mas será que sempre é a melhor opção? A resposta é: Não, existem casos

que os testes manuais serão mais adequados. Existem casos também, que o prazo

apertado não fornece tempo para automatizar, sendo o teste manual a única alternativa.

É preciso lembrar que os testes automatizados precisam ser programados nas

ferramentas, o que requer tempo e também manutenção dos mesmos. Portanto, se a

parte do software que está sendo testada de forma automatizada for mudar muito, em

curto prazo, o custo para reprogramar o teste automatizado pode ser alto. Dessa forma, a

decisão de automatizar ou não a execução de um teste, deve avaliar alguns fatores, como

por exemplo: Qual é o esforço necessário para automatizá-lo? Existe expectativa de

alterar muito o software testado? O teste deverá ser executado muitas vezes? Qual o grau

de risco da parte a ser testada?

Esses quesitos devem ser avaliados, visto que além do tempo para automatizar o teste é

preciso dar manutenção nos scripts. E a manutenção pode ser dificultada por alguns

fatores. A primeira já foi dita: Que mudança no software pode implicar na alteração do

teste automatizado. Outro fator se refere à própria ferramenta de testes, que ao passar

por uma atualização pode não ser compatível com o script de teste criado. Nesse caso,

para executar o teste automatizado seria necessário baixar a versão anterior da

ferramenta, ou então adaptar o script.

A programação dos scripts de teste passa pelos mesmos desafios do que o

desenvolvimento de um software. As boas práticas de programar, de forma que seja

reutilizável e de fácil manutenção, se aplicam a programação dos scripts de teste.

É possível perceber que possuir testes automatizados pode ser muito útil para garantir a

qualidade do software, mas é preciso conhecer os desafios envolvidos para avaliar o

custo x benefícios de cada automatização.


59

UNIDADE 13

Objetivo: Conhecer as funcionalidades de uma ferramenta para gestão de testes

Gestão de Testes - Ferramenta TestLink

O TestLink (http://www.teamst.org/) é uma aplicação web gratuita para realizar a gestão

dos testes de software. Pode ser implantado em qualquer ambiente que ofereça suporte a

PHP, MySQL e Apache.

Permite gerenciar todo o ciclo de vida do processo de software. Portanto, possui

funcionalidades para cadastrar os requisitos e os casos de testes; permite associá-los de

forma a manter a rastreabilidade; controla o plano de testes, os papéis da equipe

(testador, analista, etc.); possui estatísticas e métricas para acompanhar o progresso dos

testes; permite a priorização dos testes; definição de marcos e agrupamento dos testes

para testar determinada versão; dentre outras facilidades.

Figura 9 – Principais Funcionalidades do TestLink


60

O TestLink trabalha com quatro principais conceitos: "Projeto de Teste", "Plano de Teste",

"Suíte de Teste" e "Casos de Teste". O "Projeto de Teste" é o projeto que está sendo

gerenciado. O "Plano de Teste" representa a base para execução do teste, contendo o

subconjunto de casos de teste selecionado, a prioridade, os resultados, responsáveis e

marcos. O "Suíte de Teste" representa a organização dos casos de teste para permitir o

agrupamento em unidades lógicas. É como se fosse um "diretório" que contém casos de

testes para determinada funcionalidade. Por exemplo, é possível criar uma Suíte para um

determinado módulo e associar todos os Casos de Testes desse módulo. O "Caso de

Teste" é o documento estudado anteriormente.

Para entender melhor os conceitos, a figura abaixo apresenta um exemplo fictício criado

no TestLink para demonstração. O Projeto é a "Loja Magnun". Tem o "Plano de Teste 1"

que possui seis casos de testes atribuídos. Os casos de testes estão começando com a

sigla "LM", uma configuração realizada pelo gerente de teste cadastrado na ferramenta.

Para organizar melhor os casos de testes, tem 3 "Suítes": a suíte "Módulo Frente de

Loja", a suíte "Pagamento" e a "Venda".

Figura 10 – Exemplo de Projeto de Teste no TestLink

A figura representa uma facilidade do TestLink de visualização dos testes que passaram

(verde), falharam(vermelho),não foram executados (cinza) e estão bloqueados (roxo/azul).

O TestLink apresenta diferentes relatórios com estatísticas e métricas para servir como

base de informação para o gerente de teste acompanhar o progresso e avaliar o risco de

liberar o software. O relatório abaixo exemplifica algumas dessas métricas, como o


61

resultado do teste por prioridade, indicando, por exemplo, quantos testes de alta

prioridade falharam ou ainda não foram executados.

Figura 11 – Métricas do Plano de Teste

O TestLink permite exportar relatórios e documentos (requisitos, casos de teste, planos de

teste) para HTML, Word e Excel.

Em relação ao Caso de Teste, ele segue o modelo apresentado na Unidade 11, com

exceção dos campos "pós-condições", "dados de entrada" e "dados de saída". Alguns

usuários colocam a informação dos dados de entrada em "ações do passo", e as pós-

condições e dados de saída, em "resultados esperados". Também é possível colocar os

dados de entrada e saída em um arquivo e anexá-los ao caso de teste, tornando o teste


62

orientado a dados (DDT). Adicionalmente, caso prefira ter esses campos explícitos, o

TestLink permite criar campos personalizados.

A figura a seguir apresenta um exemplo de caso de teste no TestLink.

Figura 12 – Exemplo de Caso de Teste no TestLink

Outra facilidade oferecida pelo TestLink é atribuição de palavras-chave, facilitando a

categorização e busca dos casos de teste.


63

É possível acessar um demonstrativo on-line do TestLink em

http://testlink.sourceforge.net/demo/login.php.


64

UNIDADE 14

Objetivo: Apresentar os conceitos e as boas práticas sobre a Gestão e Registro dos Defeitos

Gestão de Defeitos

Conceito de Erro, Defeito e Falha.

Antes de estudar Gestão de Defeitos, é importante analisar os conceitos de erro, defeito e

falha, segundo o ISTQB:

• Erro (ou engano): ação humana que produz um resultado incorreto, como por

exemplo, uma ação incorreta realizada por um programador.

• Defeito (ou bug): o erro produz um defeito no código, em um software ou em um

documento.

• Falha: Se um defeito no código for executado, causará uma falha.

Portanto, de acordo com os conceitos do ISTQB, o defeito é o problema, e a falha é a

manifestação do problema. A falha também pode ser causada por condições externas:

como por exemplo, uma falha na memória RAM (radiação e magnetismo) pode impactar

no funcionamento do software por causa de problemas no hardware.

De acordo com esses conceitos, é possível que um defeito não ocasione uma falha? A

resposta é sim. Se a parte do código que contém o defeito nunca for executada, a falha

não ocorrerá. O código abaixo exemplifica esse fato.

switch(medida){ case CELSIUS; return temperatura; case FAHRENHEIT; return temperatura * 2; //defeito

}


65

No código acima, o defeito é converter Celsius para Fahrenheit multiplicando por 2. Se o

código nunca for executado com medida = FAHRENHEIT, o defeito não ocasionará uma

falha.

Gestão de Defeitos

Os defeitos (por uma questão de Didática, aqui, será tratado defeito com o significado

mais amplo, abrangendo também o conceito de falha) devem ser registrados no momento

de sua descoberta. Esse registro pode ser manual ou automático. Os desenvolvedores

tomarão conhecimento sobre a existência do defeito a partir do canal de comunicação

estabelecido pela equipe. É importante que a comunicação seja eficiente para tentar

reduzir o tempo de correção (Rios et al., 2007).

A referência do CBTS apresenta um conjunto de boas práticas interessantes para relatar

os defeitos:

• Resumo: O defeito deve ser relatado de maneira clara e resumido.

• Precisão: Antes de reportar o defeito, certificar-se que o que foi identificado é

realmente um defeito, e não uma falha no entendimento ou erro do usuário ou

testador.

• Neutralidade: Ao reportar o defeito, apresente apenas o problema sem ser

sarcástico ou colocar qualquer tipo de emoção ou humor no relato.

• Isolamento: Isolar o defeito, e reportá-lo.

• Generalização: Avaliar se o problema pode ocorrer em outras situações, avaliando

o defeito de uma forma genérica.

• Reprodução: Antes de relatar um defeito, tentar reproduzir a falha, no mínimo duas

vezes. Caso não seja possível, por se tratar de uma falha intermitente, tentar

colocar uma prova ou evidência da ocorrência, como por exemplo, um printscreen

da tela.

• Impacto: Identificar o impacto e grau de severidade do defeito para o cliente e/ou

negócio.


66

As boas práticas apresentadas visam evitar a perda de tempo dos desenvolvedores ao

identificar a origem do defeito, bem como evitar o desgaste entre a equipe de

desenvolvimento e a equipe de teste.

Os defeitos podem ser encontrados e relatados pelos testadores, usuários, clientes, help

desk, equipe de desenvolvimento, dentre outros. Porém, o desenvolvedor responsável

deverá avaliar para ver se é legítimo. A demora em reconhecer o defeito pode ser muito

prejudicial.

Após o desenvolvedor saber da existência de um possível defeito, a demora em

reconhecê-lo pode ser porque ele não conseguiu reproduzir a falha. Em alguns casos, o

desenvolvedor acaba definindo que o defeito não existe, ou posterga a sua identificação.

Uma das abordagens que pode ser tomada, para tentar acelerar o reconhecimento do

defeito, é a geração de logs pelo código para registrar o ponto em que ocorreu a falha e

se possível outras condições.

Caso haja discordância a respeito da existência do defeito, por parte dos

testadores/usuários e desenvolvedores, é preciso definir uma forma para decidir. Se o

sistema apresenta uma falha nítida e reproduzível, ou então suas funcionalidades são

diferentes do que foi especificado na documentação, então o defeito existe.

Resolução do Defeito

Como podem existir vários defeitos a serem corrigidos, bem como novos

desenvolvimentos de código a serem realizados, é necessário classificar a prioridade para

definir a ordem de correção. A priorização está relacionada com o impacto que o defeito

pode causar, avaliando se é critico; grave ou menos relevante.

Enquanto o defeito não é corrigido, é importante avaliar as medidas que podem ser

tomadas para reduzir o risco e minimizar o impacto que a falha pode provocar.

Após a correção, a parte corrigida deve ser testada novamente pela equipe de testes.

Além do teste da correção em si, testes de regressão na maioria das vezes são


67

necessários para garantir que nenhum efeito colateral foi introduzido com a alteração do

código.

É importante comunicar às partes interessadas a respeito da resolução do problema, bem

como sobre os aspectos da liberação do código corrigido.


68

UNIDADE 15

Objetivo: Conhecer uma ferramenta gratuita para Gestão de Defeitos, bem como seus benefícios.

Gestão de Defeitos - Ferramenta Mantis

Os defeitos quando encontrados precisam ser reportados aos desenvolvedores. Existem

diversas formas de realizar a gestão do defeito, desde processo manual, processadores

de texto, planilhas e até ferramentas específicas para esse fim. A utilização de uma

ferramenta apresenta benefícios como centralização dos dados, facilidade de

acompanhamento, atribuição de tarefas, dentre outros.

O Mantis é uma ferramenta gratuita para realizar a gestão

dos defeitos, disponível em http://www.mantisbt.org/. Ela foi

desenvolvida em PHP e roda nos bancos de dados MySql,

MS SQL e PostgreSQL.

O Mantis é fácil de instalar e também fácil de usar. É possível configurá-lo para ser

apresentado em português. Além de permitir fazer a gestão dos "bugs", permite gerenciar

o desenvolvimento de novas funcionalidades também, contribuindo para a gestão do que

será desenvolvido. É possível designar o responsável pelo desenvolvimento de cada item,

bem como configurar as situações que devem enviar e-mail. Assim, um e-mail pode ser

enviado aos responsáveis quando o defeito for corrigido.

O Mantis gerencia todo o ciclo de vida do defeito, desde a sua criação até sua conclusão,

passando por fases como confirmação, correção e revisão. Cada defeito recebe um

identificador numérico sequencial para facilitar o acompanhamento.

Ao logar no Mantis, o desenvolvedor visualiza uma tela com os defeitos atribuídos a ele,

os defeitos reportados por ele, bem como os defeitos do projeto, que não possuem

responsáveis, os que foram alterados e os concluídos recentemente. A figura a seguir

apresenta o painel geral dos defeitos.


69

Figura 13 – Visão geral dos Defeitos

Como é possível observar na imagem, ao final da página "Minha Visão" existe a legenda

com as respectivas cores dos "status" de cada defeito. Os status indicam:

• Novo: um novo defeito ou funcionalidade registrada que ainda não foi confirmado,

admitido, atribuído, etc.

• Retorno ("Feedback"): indica que o defeito precisa de alguma informação adicional

ou algum "feedback".

• Admitido: geralmente é utilizado pela equipe de desenvolvimento para informar que

está ciente e concorda com o defeito relatado, mas ainda não teve tempo ou

condições de reproduzir o defeito.

• Confirmado: ao contrário do defeito "admitido", no confirmado o desenvolvedor

além de estar ciente e concordar, já conseguiu reproduzir.


70

• Atribuído: o defeito já foi designado para um desenvolvedor, que passa a ser

responsável pela sua correção.

• Resolvido: defeito resolvido pelo desenvolvedor. Um defeito passa a ter o status

resolvido quando o responsável, ao editá-lo, informa que a resolução foi:

"corrigido", "não é o caso (não se aplica)", e "não será corrigido". Quando ele é

corrigido, precisa ser testado novamente.

• Fechado: defeito já corrigido e (re)testado, não sendo necessária nenhuma

informação adicional.

As duas figuras seguintes apresentam a tela para registrar um defeito. Devido ao seu

tamanho, ela foi dividida em duas imagens, e será explicada por partes.

Figura 14 – Tela de Registrar Defeito no Mantis - parte 1

A tela de registro de defeito apresenta todas as informações relevantes, estudadas na

Unidade anterior. O primeiro campo "categoria" indica em qual categoria em relação ao

projeto o defeito se encontra. As opções são cadastradas pelo usuário administrador e

normalmente contemplam os módulos de um sistema, ou outra categoria que o

administrador julgue relevante.

As opções para "frequência" da ocorrência do defeito são: sempre, às vezes, aleatório,

não se tentou, incapaz de reproduzir.


71

A "gravidade" se refere à severidade do defeito encontrado. As opções para esse campo

são: trivial, mínimo, pequeno, grande, travamento ("crash"), obstáculo ("block"), recurso

(funcionalidade nova - "feature").

A "prioridade" tem as opções: nenhuma, baixa, normal, alta, urgente e imediato.

É possível informar dados a respeito da "plataforma" e sistema operacional, caso essas

informações sejam relevantes para o defeito.

A "versão do produto" indica em qual versão o defeito foi encontrado. As possíveis

versões são cadastras pelo administrador. "Atribuir a" permite designar para o

desenvolvedor responsável. Já o "previsto para a versão" indica em qual versão o defeito

está previsto de ser corrigido.

A figura a seguir apresenta o restante da tela.

Figura 15 – Tela de Registrar Defeito no Mantis - parte 2


72

Os campos "resumo, "descrição", "passos para reproduzir", "informações adicionais",

"horas estimadas" e horas gastas" são autoexplicativos. O "carregar arquivo" permite que

o responsável anexe arquivos. Essa funcionalidade é útil para anexar, dentre outras

coisas, o print da tela de erro. A "visibilidade" indica se o defeito vai ficar visível para todos

que têm acesso ao projeto ou se vai ser restrito. "Continuar relatando" serve para o

responsável relatar outro defeito na sequência.

Acesse o demonstrativo on-line do Mantis, disponível em http://www.mantisbt.org/demo/my_view_page.php, para interagir com a ferramenta.


73

UNIDADE 16

Objetivo: Conhecer uma ferramenta gratuita para Gestão de Defeitos, bem como seus benefícios

Gestão de Defeitos - Ferramenta Mantis (Continuação)

Um recurso importante do Mantis é a organização das informações, permitindo ter

acesso, de forma facilitada, a resumos e relatórios que auxiliam na gestão e tomada de

decisão.

O Roadmap (na versão em Português está traduzido como "planejamento") apresenta os

defeitos por versão do projeto, indicando a porcentagem que já foi resolvida por versão e

o quanto ainda falta.

Figura 16 – Roadmap do Mantis


74

Já o "Resumo", apresenta estatísticas importantes a respeito dos defeitos, que são

importantes para o gerenciamento do processo de testes. Como apresenta a figura a

seguir, é possível saber a quantidade de defeitos em todos os status (aberto, resolvido,

etc), gravidade, dia, categoria, os mais ativos, os abertos há mais tempo, etc.

Figura 17 – Resumo com estatísticas do Mantis

Outras estatísticas apresentadas pelo Mantis são: status x prioridade, status x resolução,

estatísticas de relatores, eficiência dos relatores (quantos % não foram considerados

"bug"), relator por resolução e desenvolvedor por resolução.


75

Vale ressaltar que o Mantis permite gerenciar um número ilimitado de projetos, sendo que

o usuário pode escolher se deseja visualizar as informações de todos os projetos ou de

um projeto específico.

Figura 18 – Seleção do Projeto no Mantis

Outra informação interessante apresentada pelo Mantis é o histórico de mudanças por

versão. Dessa forma, se algum cliente entrar em contato relatando um defeito que já foi

corrigido, é possível identificar se a versão que ele está usando já contempla a correção.

Figura 19 – Histórico de Mudança no Mantis


76

Essas foram algumas das facilidades oferecidas pela ferramenta de gestão de defeitos

Mantis. Acesse o demonstrativo da ferramenta para conhecê-la melhor!

Uma forma facilitada para instalar o Mantis é utilizando o Xampp, uma distribuição do Apache contendo MySQL e PHP: http://www.apachefriends.org/en/xampp.html. O Xampp também permite instalar facilmente o TestLink.


77

UNIDADE 17

Objetivo: Aprender os conceitos de ferramentas para cobertura de código, a partir do exemplo da ferramenta EclEmma

Cobertura de Código - Ferramenta EclEMMA

A Cobertura de Código se refere a um conceito de teste de caixa-branca para avaliar a

porcentagem de uma classe, método, linha, etc., que foram exercitados ao se executar

um conjunto de testes. Para facilitar essa identificação, existem ferramentas que

automaticamente apontam a porcentagem exercitada por determinado, em todas as

classes do projeto. Essas ferramentas "pintam" as linhas de acordo com cores, que

normalmente são: vermelho para linha que não foi exercitada, amarelo para uma linha

parcialmente exercitada, e verde para linha que foi exercitada por completo ao menos

uma vez. Uma delas é a Emma (http://emma.sourceforge.net).

Emma é uma ferramenta gratuita para identificar a cobertura de código para Java.

Existem outras ferramentas para outras linguagens de programação, como o NCover para

.Net, por exemplo.

O interessante do Emma é que para utilizá-la não vai ser necessário mudar uma linha

sequer do seu código fonte. O Emma vai obter as estatísticas através da Java Virtual

Machine (JVM) adicionando um pequeno overhead de performance (processamento

adicional), agindo de forma silenciosa durante a execução dos testes. Os resultados

obtidos são imediatamente sumarizados e destacados ("pintados") no editor do código

fonte. O Emma produz os seus relatórios em HTML, XML ou texto e no formato HTML, é

possível relacionar os resultados ao código fonte.

Visando facilitar ainda mais essa atividade, existem adaptações para as IDEs (Integrated

Development Environment - Ambiente Integrado de Desenvolvimento). O EclEMMA

(http://www.eclemma.org/) é integração do EMMA ao ambiente de desenvolvimento

Eclipse. Portanto, representa a utilização da filosofia do EMMA no Eclipse, apresentando

os indicadores de forma interativa.


78

Ao instalar o EclEmma, o botão aparecerá. Ao executar um teste do JUnit, por

exemplo, com essa opção o código fonte testado será pintado de acordo com as cores

vermelho, amarelo e verde, conforme apresenta a figura abaixo.

Figura 20 – Código fonte "pintado" de acordo com a cobertura do código no Eclipse

Como pode ser observado na figura, a utilização do EclEMMA torna fácil a identificação

das partes do código que não foram testadas. Essa informação é bem útil visto que por

mais experiente que o programador seja, ela pode esquecer-se de criar um teste que

execute um comando importante parcialmente ou completamente, diminuindo a

probabilidade de encontrar defeitos.

Para ter uma visão geral do projeto, existe um relatório que apresenta a porcentagem de

cobertura geral, por projeto, pacotes, classes e métodos facilitando visualizar em um só

lugar o andamento dos testes nesse aspecto. Esse relatório é apresentado na figura a

seguir. Assim o gerente de projetos pode acompanhar se determinada porcentagem,

definida como mínima, para qualidade foi alcançada. Portanto, o gerente pode determinar


79

como indicador adicional que o software só pode ser liberado se tiver atingido no mínimo

85% de cobertura, por exemplo.

Figura 21 – Estatísticas de Cobertura de Pacote, Classes, Métodos,etc

Segundo as referências do EMMA, a prática diz que percentuais abaixo de 60% - 70%

representam software testado de maneira pobre, aumentando muito a probabilidade dos

defeitos serem encontrados pelos usuários. A referência afirma também que atingir 100%

não é economicamente viável. Existem muitos métodos simples que inclusive são

gerados automaticamente pela IDE (ex: os que apenas retornam o valor de um atributo)

que não justificam escrever testes apenas para exercitá-los, se eles não tiverem sido

exercitados em um teste naturalmente. A referência diz que cobertura entre 80%-90% é o

suficiente para a maioria dos casos.

É importante observar que mesmo que a classe tenha 100% do código coberto não

significa que ela esteja livre de erros e não dá para garantir que o teste foi bem elaborado.

Um software normalmente tem várias combinações de caminhos possíveis, e apenas

testar todas as linhas de um caminho não garante que os outros caminhos estão corretos.

Portanto, a cobertura de código torna-se uma ferramenta útil para indicar facilmente se

partes importantes do código não foram testadas, mas não para garantir por si só a

qualidade dos testes. Como essa ferramenta não requer nenhuma alteração no código

fonte; é gratuita e rápida. Ela é muito útil para o programador verificar a cobertura dos

seus testes desde o início do desenvolvimento e, frequentemente, a cada execução dos

mesmos.


80

UNIDADE 18

Objetivo: Visualizar os benefícios proporcionados por ferramentas para testes de unidade, a partir da explicação do JUnit

Testes de Unidade e Integração - Ferramenta JUnit

Os desenvolvedores devem testar o seu próprio código na medida em que desenvolvem e

para isso realizam testes unitários e alguns tipos de testes de integração. Para facilitar

essa atividade, existem ferramentas disponíveis com esse objetivo. O nome genérico para

ferramentas de teste de unidade é xUnit.

Nesta Unidade será apresentada a ferramenta para Java chamada JUnit. Uma grande

quantidade de linguagens de programação possuem ferramentas de teste de unidade,

como é o caso do nUnit (.Net), CppUnit (C++), dUnit (Delphi), PHPUnit (PHP), etc.

O JUnit é uma ferramenta gratuita. Foi originalmente criada por Kent Beck e Erich

Gamma, dois grandes nomes da ciência da computação. Kent Beck é o criador do XP

(Extreme Programming) e Erich Gama ficou famoso com o GoF (Gang of Four - Gangue

dos Quatro) referenciando os quatro autores do livro sobre padrões de projeto (Design

Patterns).

O conceito do xUnit foi criado por Kent Beck, um grande entusiasta de testes

automatizados. Para facilitar a organização e execução de testes de unidade, Kent Beck

desenvolveu uma ferramenta xUnit para a linguagem de programação Smalltlk. Segundo

Martin Fowler, Kent Beck e Erich Gama começaram o JUnit em um voo entre a Suíça e os

Estados Unidos em 1997, aproveitando o tempo no ar para fazer programação em par e

realizando os testes antes de desenvolver (conceitos defendidos por Kent Beck no XP).

Sem a utilização de uma ferramenta de apoio, a forma padrão de testar código unitário e

alguns casos de integração era através de debbugers ou mandando imprimir na tela o

resultado dos métodos. Essas formas são dependentes da análise humana para averiguar


81

se o resultado corresponde ao esperado, impedindo a execução automática e

desestimulando a repetição dos testes.

Ferramentas para esse objetivo facilitam essa atividade através de uma estrutura pronta.

O JUnit utiliza o conceito de asserções (asserts) para verificar se o resultado do teste

equivale ao que era esperado. Assim, o assertTrue(<condição>) verifica se a condição é

verdadeira, o assertFalse(<condição>) verifica se é falsa e o

assertEquals(Objeto1,Objeto2) verifica se dois objetos são iguais. Para informar que um

método é um teste, basta colocar a anotação @Test (importando o pacote “import

org.junit.Test") antes de sua declaração.

Caso seja preciso preparar algumas condições (ex: inicialização de variáveis) antes de o

teste ser executado é possível criar um método com a anotação @Before. Essa anotação

é útil visto que normalmente será necessário configurar determinadas características para

serem utilizado por vários testes. Já anotação @After indica que o método será chamado

após a execução do teste.

Um exemplo simples de funcionamento do JUnit: Supondo-se um método para realizar o

depósito bancário para valores maiores ou iguais à R$ 10,00. Quando o valor é menor do

que R$ 10,00 o depósito não deve ser realizado e a respectiva mensagem é exibida.

O código fonte, abaixo, exibe as mensagens de retorno e o método de realizar o depósito

em conta.

static String MSG_VALOR_MENOR_10 = "o valor de depósito deve ser maior do que R$ 9,99"; static String MSG_DEPOSITO_SUCESSO = "Depósito realizado com sucesso"; public String realizarDepositoEmConta(double valorDepositado,String numConta){ if(valorDepositado <= 10 ){ return MSG_VALOR_MENOR_10; } else{ saldo = saldo + valorDepositado; return MSG_DEPOSITO_SUCESSO; }


82

Criando os testes referentes a esse método. Antes de começar os testes, será criada uma

conta de número "12345-0" com saldo inicial = R$ 100,00. O código abaixo apresenta a

declaração da conta e do saldo inicial, bem como o método com a anotação @Before que

cria a conta com o saldo inicial. Esse método será chamado antes da execução de cada

teste.

Nessa mesma classe, adicionam-se os métodos dos testes. É importante testar primeiro a

tentativa de depósito com valor menor do que R$ 10,00. Nesse caso, o resultado

esperado é a mensagem de aviso que o valor deve ser maior do que R$ 9,99 e o saldo da

conta permanece inalterado.

Portanto o método realizarDepositoContaValorMenor10 foi criado com a anotação @Test

indicando que é um teste. Primeiro está sendo verificado se a mensagem correta está

sendo retornada ao chamar o método realizarDepositoEmConta com valor de R$ 9,99.

Utilizou-se o assertEquals para compara dois objetos do tipo "String" (texto). Em seguida,

está sendo verificado se o saldo da conta permanece inalterado, ou seja, é igual ao seu

valor inicial. Para esse caso, utilizou-se o assertTrue visto que está sendo verificada uma

condição lógica (verdadeiro ou falso).

@Test public void realizarDepositoContaValorMenor10(){ assertEquals(conta.realizarDepositoEmConta(9.99, "12345-0") ,ContaBancaria.MSG_VALOR_MENOR_10); assertTrue(conta.getSaldo()==(saldoInicial));

}

ContaBancaria conta; double saldoInicial = 100.00; @Before public void setUp(){ conta = new ContaBancaria(saldoInicial, "12345-0");

}


83

Ao executar o teste, o resultado apresentado

na imagem ao lado é exibido, indicando que

1 teste rodou com sucesso, sendo o seu

resultado a barra verde.

A seguir, é necessário rodar esse mesmo

teste com a execução do EclEmma, para ver como foi a cobertura de código obtida no

método que está sendo testado. A figura a seguir apresenta o resultado.

Como foi testado somente para valores menores do que R$ 10,00, o EclEmma

apresentou que a parte do else não foi testada.

Agora, um teste para completar a cobertura do código. O teste vai depositar R$ 10.000,00

na conta, e o resultado esperado será a mensagem de depósito realizado com sucesso e

o saldo da conta será R$ 10.100,00, ou seja, o saldo inicial + R$ 10.000,00. Apenas para

ver o comportamento do JUnit, propositalmente, declara-se que o saldo da conta deveria

ser igual ao saldo inicial.

@Test public void realizarDepositoContaValorIgual10_MIL(){ assertEquals(conta.realizarDepositoEmConta(10000.00, "12345-0") ,ContaBancaria.MSG_DEPOSITO_SUCESSO); assertTrue(conta.getSaldo()==(saldoInicial));

}


84

O código acima apresenta o teste realizarDepositoContaValorIgual10_MIL()

comparando se a mensagem de retorno é a de depósito bem sucedido, e verificando se o

saldo da conta é igual ao saldo inicial, ou seja, verificando uma condição errada.

Como o teste possui um erro, o JUnit

indica que dois testes foram

executados, e um falhou,

apresentando a barra vermelha. Ele

indica através de ícones que o teste

que causou o erro foi o

realizarDepositoContaValorIgual10_MIL(),sendo que o primeiro teste foi bem sucedido

realizarDepositoContaValorMenor10().

Para consertar o segundo teste, deve-se substituir a segunda verificação para comparar

se o saldo final é igual ao saldo inicial + R$ 10.000,00.

Ao executar esse teste, o JUnit

apresenta o resultado que os dois

testes executados foram bem

sucedidos.

Por sua vez, o EclEMMA apresenta que o método foi completamente coberto pelos testes.

Esse foi apenas um exemplo simples para demonstrar o JUnit e o EclEmma.

@Test public void realizarDepositoContaValorIgual10_MIL(){ assertEquals(conta.realizarDepositoEmConta(10000.00, "12345-0"), ContaBancaria.MSG_DEPOSITO_SUCESSO); assertTrue(conta.getSaldo()==(saldoInicial + 10000.00));

}


85

As IDEs mais utilizadas no mercado já trazem o JUnit integrado, pronto para uso,

bastando adicionar a biblioteca ao seu projeto.

Localização das Classes de Teste

É uma boa prática é separar o pacote, com os arquivos de testes, do pacote com os

arquivos de desenvolvimento. O isolamento permite que apenas o código da aplicação

seja preparado para ir para produção, desconsiderando os testes.

A figura ao lado exemplifica essa separação, em

que o código fonte está no "src" e o código de

teste no pacote "test".


86

UNIDADE 19

Objetivo: Aprender os conceitos dos objetos Mock (objetos substitutos ou "falsificados"), visualizando como funciona a ferramenta Mockito

Testes com Objetos Substitutos ou "Falsificados" (Mock Objects) - Ferramenta Mockito

Metodologias ágeis e as boas práticas incentivam que os desenvolvedores testem a todo

o momento o seu código. Na Unidade anterior foi visto como ferramentas no padrão xUnit

ajudam a atingir esse objetivo.

Para isolar os métodos ou classes durante os testes é possível utilizar os objetos "mocks",

ou seja, objetos "falsificados" ou substitutos. Os objetos mocks simulam ou imitam o

comportamento de outro objeto, permitindo definir o que o método substituto vai retornar,

de acordo com os parâmetros de entrada.

Os mocks oferecem diversos benefícios aos testes. Primeiramente, permitem isolar a

classe que está sendo testada. Também permite simular estados dos objetos que podem

ser difíceis de reproduzir, realizando os testes em um ambiente controlado. Permitem

substituir inclusive objetos que não foram implementados. Outro benefício é substituir

objetos que podem demorar mais a serem executados, como aqueles que precisam

acessar banco de dados, agilizando assim a execução dos testes.

Para entender o seu funcionamento, segue um exemplo.

Antes que um depósito possa ser realizado, é preciso verificar se a conta bancária está

ativa. Assim, o método realizarDepositoEmConta chama o método

verificarSeContaAtiva(numConta)da classe ContaDAO (padrão DAO de Data

Acess Object, ou Objeto de Acesso a Dados) que realiza uma consulta ao banco de

dados para verificar se a conta está ativa. Utilizando o mock é possível isolar o método


87

realizarDepositoEmConta , fazendo com que não seja preciso realizar a consulta ao

banco. Ou seja, determinar durante o teste com o mock:

• Quando verificarSeContaAtiva for chamado para a conta de número

"12345", é para retornar que está ativa.

• Quando verificarSeContaAtiva for chamado para a conta de número

"67891", retornando que está inativa

Dessa forma quando realizarDepositoEmConta chamar o método

verificarSeContaAtiva o objeto "falsificado" entrará em ação e retornará a resposta

determinada, sem executar de fato esse último método e, consequentemente, sem

realizar a consulta ao banco de dados.

Figura 22 – Utilização de Objeto Mock

Ferramenta Mockito

Conhecido o conceito de objetos mock, a seguir uma ferramenta que facilita a sua

criação. Sem a utilização de uma ferramenta, seria preciso alterar (ou até mesmo criar) o

código da classe original a ser substituída para verificar o parâmetro de entrada e retornar


88

um resultado esperado, poluindo o código original e adicionando trabalho extra para

depois voltar o código ao normal.

A vantagem da ferramenta é justamente essa, ela permite criar o comportamento

desejado sem ter que alterar uma linha sequer do código original.

A ferramenta apresentada também é gratuita para JAVA, chamada Mockito. O conceito se

repete para outras linguagens orientadas a objeto, que também possuem ferramentas

para esse objetivo.

O Mockito está disponível em http://mockito.org/. Para

utilizá-lo, basta realizar o download e colocar o jar no

classpath do projeto.

O Mockito é muito simples de usar. Primeiro, criea-se o objeto mockado:

Depois, determina-se que o método deve retornar quando for chamado. Exemplos:

when(mockDao.verificarSeContaAtiva("12345")).thenRetur

n(true);

when(mockDao.verificarSeContaAtiva("67891")).thenRetur

n(false);

ContaDao mockDao = mock(ContaDao.class);


89

Para ver na prática, repetiu-se o exemplo da unidade anterior adicionando a verificação se

a conta está ativa antes de realizar o depósito.

A seguir, a classe de testes. Percebe-se, no código abaixo, que poucas modificações

foram feitas para a utilização do Mockito. As alterações estão sublinhadas.

static String MSG_VALOR_MENOR_10 = "o valor de depósito deve ser maior do que R$ 9,99"; static String MSG_DEPOSITO_SUCESSO = "Depósito realizado com sucesso"; static String MSG_CONTA_INATIVA = "Conta Inativa "; public String realizarDepositoEmConta(double valorDepositado,String numConta){ if(valorDepositado <= 10 ){ return MSG_VALOR_MENOR_10; } else{ if(contaDao.verificarSeContaAtiva(numConta)){ saldo = saldo + valorDepositado; return MSG_DEPOSITO_SUCESSO; } else{ return MSG_CONTA_INATIVA; } } }


90

O método realizarDepositoContaValorMenor10()não foi alterado porque quando o valor

é menor do que R$ 10,00 o código não chega a verificar se a conta está ativa.

Já no método realizarDepositoContaValorIgual10_MIL foi adicionada a linha

when(mockDao.verificarSeContaAtiva("12345")).thenReturn(true); indicando que

quando o método verificarSeContaAtiva for chamado para a conta de número "12345",

a resposta deve ser que a conta está ativa e o método original não será executado.

Assim, na linha imediatamente abaixo, ao chamar

conta.realizarDepositoEmConta(10000.00, "12345") o realizarDepositoEmConta

utilizará o objeto "falsificado" na hora de verificar se a conta está ativa.

Executando os testes obtém-se a barra verde

indicando que os dois testes foram realizados com

sucesso.

Conta conta; double saldoInicial = 100.00; ContaDao mockDao; @Before public void setUp(){ mockDao = mock(ContaDao.class); conta = new Conta(saldoInicial, "12345", mockDao); } @Test public void realizarDepositoContaValorMenor10(){ assertEquals(conta.realizarDepositoEmConta(9.99, "12345") ,Conta.MSG_VALOR_MENOR_10); assertTrue(conta.getSaldo()==(saldoInicial)); } @Test public void realizarDepositoContaValorIgual10_MIL(){ when(mockDao.verificarSeContaAtiva("12345")).thenReturn(true); assertEquals(conta.realizarDepositoEmConta(10000.00, "12345") ,Conta.MSG_DEPOSITO_SUCESSO); assertTrue(conta.getSaldo()==(saldoInicial + 10000.00));

}


91

Visualizando a cobertura do código, verifica-se que não foi criado um teste que passe pela

situação de uma conta inativa, conforme apresenta a figura a seguir.

Criando um teste para resolver essa situação.

O código acima apresenta o teste de uma conta inativa realizarDepositoContaInativa().

Primeiro foi indicado que ao verificar se a conta "67891" está ativa, deve ser retornado

"falso". Em seguida, é verificado se ao chamar realizarDepositoEmConta para uma conta

inativa, a mensagem correta é retornada.

Executando o teste, a barra verde do JUnit

indica que os três testes foram realizados

com sucesso. Não será exibido aqui, mas o

EclEMMA indica que a cobertura para esse método foi 100%. Pronto!

O Mockito oferece ainda outros métodos para verificar, a quantidade de vezes que o

método foi chamado, se os métodos foram chamados em uma determinada ordem, dentre

outras facilidades.

@Test public void realizarDepositoContaInativa(){ when(mockDao.verificarSeContaAtiva("67891")).thenReturn(false); assertEquals(conta.realizarDepositoEmConta(50.00, "67891") ,Conta.MSG_CONTA_INATIVA);

}


92

UNIDADE 20

Objetivo: Conhecer os conceitos do Desenvolvimento Orientado a Testes (TDD)

Desenvolvimento Orientado a Testes (TDD - Test Driven Devlopment)

O Desenvolvimento Orientado a Testes mundialmente conhecido como TDD (Test Driven

Devlopment) consiste em um paradigma para criar o teste antes de implementar o código

do programa. O TDD foi popularizado por Kent Beck (o mesmo Kent Beck que criou o

JUnit) na metodologia ágil XP (eXtreme Programming) em 1999. Mesmo tendo sido

difundido junto com o XP, o TDD pode ser aplicado em qualquer metodologia de

desenvolvimento.

Segundo o próprio Kent Beck: “É uma forma previsível de desenvolvimento. O usuário

saberá quando terminou, sem ter que se preocupar com um longo rastro de bugs.”

O TDD prega que código novo só é escrito quando um teste automatizado falhar. E, na

medida em que o código vai evoluindo, as duplicações são eliminadas. Adiante, um

exemplo prático.

Em seu livro "Test Driven Devlopment by Example" (no Brasil o título foi: TDD -

Desenvolvimento Guiado por Testes) Kent Beck afirma que o TDD não é uma ideia nova

(esta Unidade foi baseada nesse livro). Segundo ele: "Desde os primórdios da

computação programadores especificam os inputs e outputs antes de precisamente

programar. TDD, pega essa ideia antiga e mistura com linguagens e ambientes de

programação modernos, e cozinha um ensopado saboroso garantido para satisfazer seu

apetite para código limpo que funcione agora.” No livro, ele agradece ao autor do livro que

leu aos 12 anos, que sugeria que se escrevesse o output esperado a partir de um input

real, e então codificasse até que os resultados atuais batessem com o resultado

esperado.


93

O mantra do TDD é "Vermelho -> Verde -> Refatoração".

1. Vermelho: Escreva um teste que falhe, e que talvez nem compile na primeira vez.

2. Verde: Faça o teste funcionar rapidamente, fazendo o que for necessário para atingir esse objetivo.

3. Refatorar – Elimine todas as duplicações criadas e que foram inseridas ao fazer o teste funcionar.

Os passos recomendados por Kent Beck para o TDD são:

• Rapidamente, adicione um teste;

• Rode todos os testes e veja o novo teste falhar;

• Realize uma pequena mudança;

• Rode todos os testes e veja todos eles serem bem sucedidos;

• Refatore para remover duplicidades;

• Boas práticas no tempo certo. Primeiro faça rodar, posteriormente faça certo.

Assim, a ideia é que primeiro escreva o teste. Em seguida, faça o teste ser bem sucedido.

No conceito TDD, fazer com que a barra (estilo JUnit) fique verde, prevalece sobre

qualquer outro ponto. Segundo Kent Beck, essa mudança "estética" é difícil para

desenvolvedores e engenheiros de software experientes, que só conseguem escrever o

código correto para passar em um teste. Ainda de acordo com ele, tornar “verde” rápido

perdoa todos os pecados, mas apenas por um momento. Após fazer o teste "passar", faça

corretamente. Em relação ao "faça corretamente" Kent afirma que no momento em que o

código está se comportando corretamente, elimine os "pecados" do passado recente,

voltando ao caminho estreito e reto da integridade do software. Nesse momento, remova

a duplicação que introduziu e faça a barra ficar verde rapidamente. Esse conceito prega

que primeiro seja resolvido à parte do problema “que funcione”. Então, resolva a parte

“código limpo”.


94

Seguindo esses passos, normalmente será percebido:

• Como cada teste pode cobrir um pequeno incremento da funcionalidade

• Quão pequena e "feia" a mudança pode ser para fazer o novo teste rodar

• A frequência com que os testes são executados

• Quantos passos pequenos compõem uma refatoração

Ao realizar TDD, recomenda-se que se tenha uma lista de tarefas para lembrar o que

deve ser feito e, ao mesmo tempo, manter o foco. Um item finalizado deve ser riscado da

lista. Ao pensar em um novo teste para escrever, adicione à lista.

Segundo o livro do Kent Beck, se uma solução simples e limpa for óbvia, então a escreva.

Se a solução for simples e limpa, mas for tomar mais do que um minuto para ser

executada, deve-se escrever na lista e voltar para o problema principal, que é fazer a

barra ficar verde em segundos.

Para atingir rapidamente o "verde", duas estratégias são utilizadas.

1. "Fingir/Falsificar": consiste em forçar o resultado, como por exemplo, retornar uma

constante e gradualmente substituindo por variáveis até chegar ao código real

(Será mais exemplificado da próxima Unidade)

2. Utilizar a implementação óbvia, já digitando a solução real.

Kent Beck varia entre as duas estratégias quando está utilizando o TDD na prática.

Quando tudo está fluindo tranquilamente e ele sabe o que digitar, ele vai pela

implementação óbvia, sempre rodando os testes. Assim que ele obtém um “vermelho”

inesperado, ele recua, volta para a implementação “falsa”, e refatora o código correto.

Segundo Erich Gamma, a maioria das pessoas que aprende TDD identifica que suas

práticas de programação mudaram para melhor. Ele cunhou o termo “Test Infected”

(Contagiado pelos Testes) para esse tipo de situação. Por outro lado, alguns engenheiros


95

de software aprendem TDD e continuam com sua forma padrão de desenvolvimento,

deixando o TDD para ocasiões especiais em que não sente que está tendo progresso.

"Você pode se encontrar escrevendo mais testes antecipadamente e trabalhando em

passos menores do que você poderia imaginar que seria possível" - Kent Beck.


96

UNIDADE 21

Objetivo: Ver aplicação dos conceitos do TDD, com um exemplo na prática

Exemplo de TDD na Prática

Após ter estudado os principais conceitos do TDD, será apresentado um exemplo prático

do TDD, baseado no livro "Test Driven Devlopment by Example" do Kent Beck.

O exemplo apresentado refere-se à sequência de Fibonacci. A série de Fibonacci

(representado abaixo por F()=) tem a seguinte formação:

• F(0) = 0

• F(1) = 1

• F(2) = 1

• F(n-1) + F(n-2), para qualquer outro número maior do que 2

Assim, tendo n = 3, F(3) = F (3 - 1) + F (3 - 2) = F (2) + (1) = 1 + 1 = 2. Já para n=4, F(4) =

F(3) + F(2) = 2 + 1 = 3. Portanto a sequência é: 0,1,1,2,3,5,8,13, ... .

Agora que a série de Fibonacci foi apresentada, segue à resolução com o TDD.

O primeiro teste apresenta que Fib(0) = 0. Seguindo os conceitos do TDD, antes de

desenvolver o código, é importante desenvolver o teste para ele.

@Test

public void testFibonacci() {

assertEquals(0, fibonacci.fib(0));

}


97

O código acima representa esse teste escrito com o JUnit, que já foi estudado neste

Módulo. Portanto, verifica (assertEquals) se o resultado de fibonacci.fib(0)é 0. Esse

teste não vai nem compilar, viso que a classe Fibonacci ainda nem foi criada. O objetivo é

esse mesmo, lembrando o mantra TDD: Passo 1: "Vermelho – deve-se fazer um teste que

falhe, e que talvez nem compile na primeira vez".

Passo 2: "Verde - Fazer o teste funcionar rapidamente, fazendo o que for necessário para

atingir esse objetivo". Portanto, deve-se criar a implementação de Fibonacci mais simples

possível para passar no teste criado.

Executando o teste, atinge-se o objetivo de

conseguir a barra verde o mais rápido

possível. Para isso, cria-se um código que

independente do número de entrada, sempre

retornará o número zero.

Escrevendo o segundo teste, para Fib(1)= 1.

O teste vai falhar, visto que de acordo

com o código implementado Fib(1) =0

ao invés de 1. Esse comportamento

@Test




}

public int fib(int n) {

return 0;

}


98

está de acordo com o que prega o TDD. Agora, acerta-se o código, desenvolvendo uma

implementação mais simples para obter a barra verde.

O código bem simples, que retorna 0 quando n = 0, e 1 para todos os demais números de

entrada foi criado, e o teste passou.

O próximo teste é Fib (2) =1.

Esse teste vai passar, visto que o código está sempre retornando 1, para números

diferentes de 0. Se reparar, o teste, cada linha é cópia da linha anterior alterando apenas

dois números. Seguindo a recomendação do TDD, refatore para eliminar a duplicidade (se

aplica ao teste também).

@Test public void testFibonacci() { int casos[][]= {{0,0},{1,1},{2,1}}; for (int i= 0; i < casos.length; i++){ assertEquals(casos[i][1], fibonacci.fib(casos[i][0])); } }

@Test





}

public int fib(int n) { if(n==0)return 0; return 1; }


99

Portanto, o teste foi refatorado de forma que para inserir novos testes, basta colocar na

matriz "casos" o par "{n, resultado esperado}".

O próximo teste é Fib (3) = 2. Adicionando no teste {3,2} e rodando, obtém-se o seguinte

resultado:

A barra vermelha é apresentada com

a mensagem de erro do JUnit: era

esperado o resultado 2 mas foi

obtido 1. A mensagem de erro do

JUnit acompanha todos os testes

vermelhos, ela foi omitida nos outros

exemplos, mas foi inserida aqui para conhecimento de mais esse recurso.

Alterando o código para o teste passar:

Para fazer o teste Fib(3) passar o número 2 está sendo retornado para números de

entrada > 2. Mas utilizando o conhecimento sobre Fibonacci, sabe-se que F(3) = 2 porque

F(3) = F(3 -1) + F(3-2) = 1 + 1 = 2. Portanto, vamos aplicar essas substituições passo a

passo no código, antes de ir para o próximo teste. Cada alteração no código, o JUnit deve

ser rodado novamente para ver se os testes anteriores continuam funcionando. A primeira

mudança é substituir o 2 por 1 + 1.

public int fib(int n) { if(n==0)return 0; if(n<=2)return 1; return 1 + 1;

}

public int fib(int n) { if(n==0)return 0; if(n<=2)return 1; return 2; }


100

Como se sabe que o primeiro 1 = F(n-1), se faz essa alteração.

A seguir, substituir o segundo 1 = F(n -2).

Pronto, agora todos os demais testes vão passar. Rodando cada um deles por vez: Fib(4)

= 3, Fib(5)=5, Fib(6)=8, etc., obtém-se a barra verde em todos.

Chega-se então à resolução do problema, utilizando-se os conceitos do TDD:

1. Vermelho: Escreva um teste que falhe, e que talvez nem compile na primeira vez

2. Verde: Faça o teste funcionar rapidamente, fazendo o que for necessário para atingir esse objetivo.

3. Refatorar – Elimine todas as duplicações criadas, que foram inseridas ao fazer o teste funcionar.

O próximo passo é realizar o teste para valores ilegais, adicionando a proteção ao código

para tratar os números negativos.

public int fib(int n) { if(n==0)return 0; if(n<=2)return 1; return fib(n-1) + fib(n-2);

}

public int fib(int n) { if(n==0)return 0; if(n<=2)return 1; return fib(n-1) + 1;

}


101

Tamanho dos passos

Algumas pessoas podem ter achado os 3 últimos passos muito pequenos: substituir 2 por

1 + 1; substituir 1 + 1 por fib(n -1) + 1; e por fim substituir fib(n-1) +1 por fib(n-1) + fib(n-2).

Se os passos parecerem muito pequenos, lembre-se que TDD não prega que se realizem

passos pequenos, mas que se tenha a habilidade de realizar os passos pequenos.

Segundo Kent Beck, ele não codifica no dia a dia com passos tão pequenos. Mas quando

as coisas começam a complicar o mínimo possível, ele se diz contente por poder realizar

os passos pequenos. Ele recomenda que se tentem passos pequenos com um exemplo.

Se conseguir fazer os passos muito pequenos, certamente conseguirá fazê-los do

tamanho correto. Se apenas fizer passos grandes, nunca saberá quando passos menores

são apropriados.

Após ter visto o exemplo prático, pode ser uma boa pedida estudar novamente a Unidade

anterior, visto que os conceitos estão mais claros e o aprendizado de um paradigma novo

será reforçado.


102

UNIDADE 22

Objetivo: Conhecer a ferramenta Selenium para automatizar testes de aplicações Web

SELENIUN - Ferramenta para Gravar/Executar Testes em Browsers. I

O Selenium é uma ferramenta gratuita muito boa para automatizar

os testes de aplicações WEB. Com o Selenium é possível gravar

todos os passos (cliques, inserção de dados, etc.) realizados pelo

usuário em um site, para depois reproduzir os mesmos.

Ela suporta diferentes linguagens de programação como Java,

Javascript, Ruby, PHP, Python, Perl e C#, e a quase todos os browsers como Firefox,

Google Chrome, Internet Explorer, etc.

O Selenium foi criado em 2004 por Jason Huggins da ThoughtWorks, quando ele estava

realizando testes de uma aplicação web. Ao perceber que existia uma forma melhor de

executar os testes, sem ter que executá-los manualmente a cada mudança, ele

desenvolveu uma biblioteca Javascript para realizar interações com a página, sendo que

era possível rodar os testes em diferentes browsers. Essa biblioteca se tornou o núcleo do

Selenium, uma ferramenta inovadora visto que na época não existia nenhum outro

produto que permitia controlar o browser de uma linguagem de programação escolhida

pelo programador (Hunt et al., 2011).

Em 2006, Simon Stewart engenheiro do Google iniciou um projeto chamado de WebDriver

para contornar algumas limitações do Selenium, já que o Google era um usuário assíduo

dessa ferramenta. Em 2008 o WebDriver e Selenium foram unificados. Assim surgiu o

Selenium 2 (Selenium WebDriver), enquanto o anterior era o Selenium 1 (Selenium

Remote Control - RC). O mais atual possui uma API mais coesa e orientada para objetos

com funcionalidades que derrubam algumas limitações da implementação antiga. O

Selenium 2 também roda a interface do primeiro Selenium, para prover compatibilidade.


103

Mesmo com a existência da versão 2, o Selenium 1 ainda recebe suporte porque,

segundo o próprio manual, existem funcionalidades que podem não ser inseridas no

Selenium 2 por um bom tempo (Hunt et al., 2011).

O Selenium IDE (Integrated Development Environment - Ambiente Integrado de

Desenvolvimento) é um plugin para Firefox para facilitar a criação dos scripts de teste,

pois grava todas as ações dos usuários, na medida em que ele "navega" pelo site ou

aplicação web. Após salvar, é possível exportar o código para as várias linguagens de

programação que são suportadas pelo Selenium, de forma a permitir a execução futura.

Mesmo o IDE sendo somente para Firefox, os testes criados podem ser executados em

qualquer browser compatível através da linha de comando do Selenium RC. Ou seja, para

gravar os passos de forma facilitada vai ser necessário utilizar o Firefox, mas para

executá-los é possível utilizar qualquer browser.

O Selenium IDE não fornece iterações (while, for, etc), nem condicionais (if, else,etc) para

os scripts, e não existe planejamento até o momento para adicionar essas

funcionalidades. Isso porque o IDE tem o objetivo de ser uma ferramenta para prototipar

os testes rapidamente e mesmo sem essas funcionalidades, é uma das formas mais

eficientes de se desenvolver os scripts de teste para aplicações web. Caso deseje utilizar

as iterações e condicionais para realizar testes mais complexos, é possível exportar o

script criado no IDE para uma das linguagens de programação e em seguida alterar o

código, funcionando tanto para o Selenium 1 e 2.

Outra alternativa para utilizar iterações e condicionais, mas do próprio browser, é através

da instalação de uma extensão, chamada "goto_sel_ide.js" (disponível em:

https://addons.mozilla.org/pt-BR/firefox/addon/flow-control/).

Para instalar o Selenium, vá até a página http://seleniumhq.org/download/. Para instalar o

Selenium IDE, utilize o FireFox, clique no link e confirme - assim os dois já são integrados.

Realize também o download do Selenium RC. Para rodar o Selenium IDE, utilize uma das

duas formas apresentadas na imagem abaixo.


104

Figura 23 – Formas de rodar o Selenium IDE

Ao executar, a tela do Selenium será exibida. Por padrão o botão vermelho já vem

marcado, indicando que o modo de gravação está ativado.

Figura 24 – Selenium IDE

Com o botão de gravação ativado, tudo que o usuário fizer na página será gravado.


105

UNIDADE 23


SELENIUN - Ferramenta para Gravar/Executar Testes em Browsers II.

Repare na próxima figura que o Selenium IDE gravou a navegação do usuário, que

consistiu em abrir a página do Mantis e em seguida digitar o nome "pedro" no campo

"username". A figura destaca em vermelho o comando gerado pelo Selenium ao digitar o

username.

Figura 25 – Gravação dos passos do usuário com o Selenium IDE


106

A figura mostra apenas até o momento que foi digitado o username, mas continuando o

processo para fazer o login, ao informar a senha e clicar no botão "Login" o Selenium

salvará todos esses passos. Interrompendo a gravação e clicando no botão do Selenium

"play", todos os passos gravados serão executados, fazendo o login automaticamente no

exemplo, casos os dados informados sejam válidos. Simples e genial!

Portanto, durante a gravação o Selenium IDE automaticamente adicionará os comandos

no script de acordo com as ações do usuário, como por exemplo: clicar em um botão, em

um link, checkbox, etc; preencher campos da página (ex: login, senha, nome, idade, etc);

e selecionar uma opção de uma caixa de seleção ("drop down").

É importante perceber que normalmente ao preencher os campos da página, é preciso

sair do campo para que o comando "type" seja gravado, ou seja, na figura anterior, após

informar o "username", foi preciso ir para o próximo campo (ou clicar em outro ponto da

página) para o comando ser gravado.

Ao clicar em um botão, link, etc., o comando "click" ou "clickAndWait" será gravado. O

"clickAndWait" deve ser utilizado quando for preciso aguardar alguma situação, como por

exemplo, a próxima página ser carregada. Caso contrário, o teste vai continuar

executando, antes da página ter carregado todos os elementos, o que pode provocar

falhas no teste. Isso acontece porque a velocidade de execução do Selenium (rodando na

máquina local) é mais rápida do que o tempo de resposta do servidor.

A IDE oferece algumas opções para executar os casos de

teste. É possível rodar o script gerado por completo,

interromper e continuar, alterar a velocidade da execução, executar uma linha por vez e

rodar todos os scripts do "Test Suite". É possível executar também um único comando,

sendo essa funcionalidade útil para verificar se o comando que se está desenvolvendo

está correto, sem ter que executar o teste inteiro novamente. Ao clicar com o botão direito

nos comandos é possível incluir opções que permitem "debugar" o script, como inserir um

"breakpoint" para forçar uma interrupção em um comando particular, e definir um ponto de

início no meio do teste.

Os comandos do Selenium, frequentemente, são chamados de "Selenese" e, ao serem

colocados em sequência, formam o script de teste. O Selenium oferece uma boa


107

quantidade de comandos que permitem verificar: se determinado texto está presente na

página, o tamanho da janela, mensagens, a existência de um elemento na página, dentre

inúmeras outras funções. Ao clicar em um elemento da página com o botão direito do

mouse, a lista de comandos e parâmetros do Selenium referentes ao mesmo são

exibidos, conforme apresenta a figura a seguir. Essa facilidade economiza tempo e é uma

excelente forma de aprender a sintaxe do Selenium.

Figura 26 – Exibição dos comandos disponíveis para determinado elemento

A sintaxe dos comandos é simples, consistindo de 3 parâmetros: o comando em si, o alvo

da ação e o valor. Os parâmetros não são sempre obrigatórios, variam de acordo com o

comando selecionado. O comando abaixo, extraído da Figura 25 informa que será

digitado (type) o valor "pedro" no campo "username".

Comando Alvo Valor

type Name=username pedro

Figura 27 – Estrutura de um comando "Selenese"


108

Existem três tipos de comandos: as ações - como digitar (type), clicar (click), etc.; os

acessors que salvam valores em variáveis, como o comando "store"; e os assertions

(verificadores) que verifica se algo está conforme o esperado, como por exemplo,

"garanta que a palavra 'Administrador' está presente na página após o login".

Os assertions, por sua vez podem ser de três formas: comando "assert", que aborta o

teste em caso de alguma falha; comando "verify" que registra a falha no log, mas

prossegue com o teste; e o "waitFor" que espera até a condição ser verdadeira (espera

durante um timeout configurado). O "waitFor" é importante para testar aplicações Ajax.

Quanto à diferença do "assert" e "verify", cada um tem sua utilidade. Por exemplo, se o

teste verificar que foi direcionado para uma página diferente da esperada, geralmente não

vai fazer muito sentido continuar com o teste, e nesse caso usaria o "assert" para abortar

em caso de falha. Por outro lado, pode ser desejado testar vários elementos de uma

mesma página de uma vez, mesmo que um deles apresente erro, utilizando assim o

"verify".

Segue abaixo alguns dos comandos mais utilizados para testar as páginas com o

Selenium:

• open: utiliza a URL para abrir a página

• click/clickAndWait: clica no elemento especificado no parâmetro "alvo"

• verifyTitle/assertTitle: verifica se o título da página contém determinado texto

• verifyTextPresent: verifica se o texto especificado está em algum lugar na página

• verifyText: verifica se o texto especificado está em um determinado elemento HTML

• verifyElementPresent: verifica se um elemento como link, parágrafo, etc., está presente na página

• waitForElementPresent: aguarda até o elemento HTML estar presente na página


109

UNIDADE 24


SELENIUN - Ferramenta para Gravar/Executar Testes em Browsers III

Conforme foi possível observar, muitos comandos precisam identificar um elemento

HTML (alvo) para realizar determinada ação. Mas como fazer essa identificação? A

seguir, algumas formas, tomando como exemplo a figura abaixo.

Figura 28 – Exemplo de uma página HTML simples para Login (Hunt et al., 2011)

Localizar por identificador: localizar o primeiro elemento HTML correspondente ao "id". Se

o "id" não estiver presente, retornar o primeiro elemento correspondente ao "name".

Portanto se no "alvo" estivesse identifier=loginForm, o comando seria realizado sobre o

elemento da linha 3. Se estivesse identifier=username, o comando seria realizado sobre o

elemento da linha 4.

Localizar por id: localizar o primeiro elemento correspondente ao "id", sendo que não se

verifica no "name". Portanto, se no "alvo" estiver id=loginForm, o comando será realizado

sobre o elemento da linha 3.


110

Localizar por nome: localizar o primeiro elemento correspondente ao "name". Voltando ao

exemplo da Figura 25, percebe-se que essa estratégia foi utilizada visto que o "alvo" está

name=username. Portanto, o comando especifica para digitar (type) o valor "pedro" no

alvo que name=username. Se dois elementos tiverem o mesmo nome, é possível utilizar

outro atributo, em conjunto, para identificação. Assim, um alvo que especifique

"name=continue value=Clear" indica para o comando ser realizado no elemento da linha

7.

Localizar por Xpath: é uma maneira versátil de localizar um elemento, facilitando

identificações do tipo: "localizar a quinta linha de uma tabela". É possível localizar através

do caminho absoluto (que não é recomendado visto que o teste fica propenso a falhar

com uma mudança pequena da aplicação) ou caminho relativo. Portanto, nesse exemplo,

se o "alvo" for xpath=/html/body/form[1], o comando será aplicado ao elemento da linha 3,

visto que é o primeiro "form". Esse é um exemplo de caminho absoluto. Se no "alvo"

estiver //form[@id=’loginForm’]/input[4], o comando será realizado sobre o elemento da

linha 7, visto que esse caminho relativo primeiro identificou o "form de id=loginForm", para

depois localizar o quarto input desse form. Vale observar que começar com "xpath" ou "//"

produz o mesmo resultado.

Para saber mais sobre Xpath, acesse o tutorial disponível em:

http://www.w3schools.com/Xpath/.

Existem formas de localizar os elementos HTML também pelo texto do link, por DOM

(Document Object Model), utilizando Javascript ou por CSS (Cascading Style Sheets).

Em relação à comparação de determinado texto da página, o Selenium oferece a

possibilidade de verificar por padrão de texto, sendo essa uma forma flexível já que não

vai ser necessário utilizar o texto exato. Uma das formas de padrão de texto é através da

expressão regular. Assim, "verifyTextPresent regexp:.*Administrador.*Bem.*Vindo",

verifica se existe texto contendo as palavras "Administrador", "Bem" e "Vindo", mesmo se

estiver com outras palavras ou caracteres entre elas.

Agora, que já se conhece um pouco mais sobre os comandos do Selenium, o próximo

passo é gravar um teste para depois executá-lo automaticamente. O teste gravado será: ir


111

à página de demonstração do Mantis para ver se o texto de erro aparece na página ao

tentarmos efetuar login com usuário e senha inválidos.

O teste consiste em abrir a página de demonstração do Mantis, digitar o nome "pedro" no

campo "username", digitar "pedro" no campo "password", clicar no botão, e verificar se

aparece alguma mensagem contendo as palavras "disabled","blocked"ou"incorrect",

indicando usuário e senha inválidos. A tabela abaixo apresenta os comandos gerados ao

gravar o teste com o Selenium.

Comando Alvo Valor

open /demo/login_page.php?return=%2Fdemo%2Fmy_view_page.php%3F

type name=username pedro

type name=password pedro

clickAndWait css=input.button

verifyText css=font *disabled*blocked*incorrect*

Figura 29 – Teste de Login errado com Selenium

A figura a seguir apresenta a execução automática de todos os passos gravados (figura

anterior), com destaque para indicação da execução com sucesso do teste no Selenium e

a mensagem informando do login sem sucesso. Portanto, automaticamente o Selenium

informou o usuário "pedro", senha "pedro", clicou no botão para login e verificou se a

mensagem de erro foi apresentada.


112

Figura 30 – Resultado da execução do Selenium

É possível salvar o teste e executá-lo posteriormente. A ferramenta permite carregar

vários testes salvos, e executar todos. O conjunto de testes é chamado de "Test Suite". O

painel em destaque, na figura anterior, mostrará quantos dos testes executados falharam.

Após criar o teste, é possível exportá-lo para uma das linguagens de programação

suportadas, conforme mostra a figura a seguir. No exemplo, o arquivo está sendo

exportado para a linguagem de programação Java (opção JUnit).


113

Figura 31 – Exportando os comandos gravados para uma linguagem de programação

Uma vez exportado para linguagem de programação desejada, é possível continuar

programando normalmente.

Para executar o teste a partir do Java, basta colocar o "jar" (ex: selenium-java-2.0b2.jar)

do Selenium no classpath do projeto (para demais linguagens, consulte o manual de

referência). O servidor (Selenium 1 ou 2) deve estar rodando quando for executar o

arquivo ".java" que foi salvo, bastando para isso digitar na linha de comando "java –jar

selenium-server-standalone-2.0b2.jar". Ou então colocar como atividade.


114

UNIDADE 25

Objetivo: Visualizar o funcionamento de uma ferramenta para realização de testes de performance e estresse, através da demonstração do JMeter

Teste de Performance e Estresse - Ferramenta JMeter

Para saber como o sistema se comporta com utilização dos recursos padrão, no limite, e

acima do limite é importante realizar os testes de performance e os de estresse.

Antes de iniciar os testes de performance e estresse, é importante responder algumas

perguntas: Qual é o número médio (conhecido ou esperado) de usuários em uma carga

normal? Qual é o pico de usuários esperado? O servidor em que os testes serão

realizados pode ser interrompido? Qual momento adequado (ex: madrugada, final de

semana, etc.) para realizar os testes de performance e estresse nesse servidor? Quais

são os resultados esperados (ex: tempo de resposta por quantidade de usuários)?

O JMeter (http://jakarta.apache.org/jmeter/) é uma ferramenta

gratuita da Apache pare realizar testes de performance e

estresse em Aplicações Web, Banco de Dados, Servidores

FTP, dentre outros. Para realizar os testes em aplicações Web, o JMeter permite que

você salve a navegação pelo site, para posteriormente durante a execução do teste

reproduzir os mesmos passos.

A seguir, os passos necessários para gravar os testes e em seguida executá-los. Após

efetuar o download do JMeter, basta acessar a pasta 'bin" e clicar 2 vezes em "jmeter.bat"

(para usuários Windows). O JMeter abrirá contendo "Test Plan"(plano de teste) e

"WorkBench" (área de trabalho). O WorkBench é a parte em que será realizada a

configuração para gravar o teste, e o Test Plan é o local onde o teste será salvo para

poder ser executado.


115

Clique com o botão direito em Test Plan, e em seguida selecione Add>Threads

(Users)>Thread Group. Dessa forma o Thread Group será adicionado ao seu plano de

teste. O Thread Group representa o número de threads (processos, ou nesse caso

também pode ser usuários) que acessarão o site em paralelo.

Clique com o botão direito em

Thread Group, e em Add>Config

Element> HTTP Request Defaults

(conforme imagem ao lado), para

adicionar as configurações da

requisição Http.

No elemento HTTP Request

adicionado, informe a URL ou IP da

aplicação Web que deseja testar. Para

não sobrecarregar nenhum site, vou

realizar a demonstração com um

Mantis que instalei localmente. Deixe

os outros campos vazios.

Vamos agora para o WorkBench,

configurar a parte responsável pela

gravação do teste. Clique com o

botão direito no WorkBench,

Add>Non-Test Elements>HTTP Proxy Server. Esse elemento serve para gravar as

requisições que serão enviadas para o servidor. Vale ressaltar que essa parte não será

salva no plano de teste, ou seja, ao fechar o teste no JMeter e abrir novamente, será

preciso configurar um novo HTTP Proxy Server, visto que esse elemento é utilizado

apenas no momento de gravar o teste, e não durante a sua execução. Para aplicações

que precisam de cookie, adicione um HTTP Cookie Manager


116

Quando o JMeter grava uma execução, ele grava todas

as requests das páginas, incluindo requests de imagem,

stylesheets, arquivos javascript, etc. Portanto no HTTP

Proxy Server é importante filtrar os arquivos que não

devem ser salvos no plano de teste. A imagem ao lado

apresenta a configuração para excluir os arquivos do tipo css, gif, png e ico (padrão:

".*\nome").

Para poder gravar, será preciso

configurar o proxy do navegador. Vamos

demonstrar como fazer no Firexox: clique

em Ferramentas>Opções>

Avançado>Rede> Configurar conexão.

Na janela de "Configurar conexão", selecione a

opção "Configuração manual de proxy:", coloque

HTTP: localhost e a porta 8080. Marque a opção

"Usar este proxy para todos os protocolos". Repare

se "Sem proxy para" não contém "localhost". Se

tiver, apague. É importante lembrar-se de voltar ao

modo padrão ("Sem proxy") após salvar os testes,

caso contrário não conseguirá acessar páginas

nesse navegador quando o JMeter estiver desligado.


117

Volte na tela HTTP Proxy Server do

JMeter e clique em "Start" para começar

a gravar o teste (conforme imagem ao

lado).

Em seguida vá ao navegador com o

proxy configurado e digite o endereço

da aplicação web/site que deseja testar.

No caso desta demonstração:

http://localhost/mantis/. A partir de agora, toda a navegação será salva no JMeter,

incluindo os dados informados para login e senha, as páginas clicadas, etc.

Teste as suas configurações e verifique se está gravando o que interessa, e exclua o

restante. Após realizar a navegação desejada, volte no JMeter e clique no botão "Stop"

para encerrar a gravação.


118

UNIDADE 26

Objetivo: Objetivo: Visualizar o funcionamento de uma ferramenta para realização de testes de performance e estresse, através da demonstração do JMeter

Teste de Performance e Estresse - Ferramenta JMeter IV

A figura abaixo apresenta o resultado da gravação do teste. É possível perceber que

todas as páginas navegadas foram salvas no Thread Group, em conjunto com os dados

pertinentes. Por exemplo, na página de login, foram salvos os dados de username e

senha para o JMeter poder realizar o login automaticamente.

Figura 32 – Páginas salva e Dados da Página de Login

O JMeter oferece diferentes estatísticas para permitir acompanhar o resultado dos testes.

Antes de executar o teste, vamos adicionar duas opções de visualização. Clique com o

botão direito em Thread Group, e em Add>Listener>View Results Tree, e em


119

Add>Listener>View Results in Table. Vamos agora configurar os dados para executar o

teste, como informações do número de usuários simultâneos e de quanto em quanto

tempo novos usuários devem ser iniciados. Para isso, clique em Thread Group e

configure os dados a seguir.

Informe o número de usuários (nesse caso os

threads) que devem acessar a aplicação durante o

teste. O "Ramp-Up Period" serve para informar ao

JMeter em quanto tempo ele deve iniciar todos os

usuários. Assim, se for configurado 10 usuários com

um Ramp-Up de 20 segundos, o JMeter começará

um novo usuário a cada 2 segundos (20/10) visto que tem 20 segundos para iniciar os 10

usuários. No caso da figura, os 10 usuários vão ser iniciados em 1 segundo. O "Loop

Count" serve para informar quantas vezes o teste deve ser repetido.

Uma vez definido esses parâmetros, clique em Run>Start. O quadro verde e os números

no canto superior direito indicam que o teste está rodando. Acesse o View Results Tree e

o View Results in Table (ou algum outro que tenha adicionado) para visualizar

informações e estatísticas a respeito da execução.

Figura 33 – Informações apresentadas em 'View Results in Table" do JMeter


120

No "View Results in Tables" é possível visualizar o tempo de início, o nome do thread, a

página acessada, o tempo de execução, status e número de bytes. No View Results in

Tree é possível ver mais detalhes de cada item testado, como o resultado, a requisição e

resposta de uma tentativa de acesso. A figura abaixo apresenta a visualização da

resposta em HTML a uma requisição para a página login.php.

Figura 34 – Informações apresentadas em 'View Results Tree" do JMeter

A quantidade de threads executando no JMeter vai ser limitada pela capacidade do

hardware. Outro ponto que influencia, é a velocidade do servidor. Um servidor rápido

responde às requisições mais rapidamente e assim, o JMeter trabalhará mais, de forma

que cada thread tenha que esperar para acessar o CPU, por isso a informação sobre o

tempo pode ficar menos precisa. Portanto para realizar testes de performance/estresse

em larga escala, pode ser necessário executar paralelamente várias instâncias do JMeter

sem interface gráfica em diferentes máquinas.

Além dos testes da aplicação web, é possível monitorar a utilização dos recursos e

performance do servidor. Diferentemente do teste da aplicação que pode ser realizado em


121

sistemas desenvolvidos em qualquer linguagem de programação, o monitoramento do

servidor só pode ser realizado em "Servlets Container" com suporte para o JMX (Java

Management Extension, ou em português, Extensão de Gerenciamento Java).

A figura abaixo apresenta um gráfico de performance monitorado em um servidor.

Figura 35 – Monitoramento do Servidor com JMeter (Apache,2011)

Note que as informações disponíveis nesta Unidade são para fins de estudo e não devem ser utilizadas para realizar ataques a servidores, ficando o aluno responsável pela autorização de utilizar ferramentas para testes de estresse/performance nos servidores que precisam ser testados. Aja sempre de forma ética e não se torne um "criminoso", evitando inclusive problemas judiciais.


122

UNIDADE 27

Objetivo: Aprender os conceitos da prática de Integração Contínua que visa aumentar a qualidade do código

Integração Contínua

A Integração Contínua é um termo originado do processo de desenvolvimento ágil do XP

(eXtreme Programming). Entretanto, qualquer metodologia pode se beneficiar da

Integração Contínua.

A Integração Contínua consiste em uma prática dos desenvolvedores integrarem o código

alterado/desenvolvido ao projeto principal em uma frequência alta, muitas vezes

diariamente, com intuito de descobrir o mais cedo possível se as alterações não

introduziram novos defeitos ao projeto. Essa prática pode ser realizada manualmente,

mas é preferível contar com ferramentas que reduzem bastante o esforço.

Controle de Versão de Código

Um ponto chave para realização da integração contínua é contar com uma boa

ferramenta de controle de versão do código fonte. Existem excelentes ferramentas

gratuitas para esse fim, e uma das mais populares é o Subversion

(http://subversion.apache.org/) que é considerado por muitos o substituto do CVS.

Os benefícios de utilizar um sistema para controle de versão são inúmeros, como: permitir

restaurar versões antigas, comparar um código novo com um antigo que funcionava;

gerenciar as alterações do código em um único repositório, dentre outros. Independente

de utilizar integração contínua é muito importante que todo projeto de software utilize um

sistema de controle de versão.


123

De forma geral, é mantida no sistema de controle de versão uma linha de

desenvolvimento principal do projeto, contendo documentação, código fonte, scripts de

teste, arquivos de propriedades, bibliotecas e todos os demais recursos necessários para

rodar o projeto. É possível criar linhas alternativas de desenvolvimento (normalmente

chamadas de "branches") de forma que essas não atrapalhem o desenvolvimento atual

do projeto. Um exemplo de utilidade é restaurar uma versão antiga para corrigir um

determinado bug, sem que essa alteração atrapalhe o desenvolvimento da versão atual

sendo realizada pelos outros desenvolvedores.

Antes de iniciar o desenvolvimento, o desenvolvedor baixa o código do repositório central

para sua máquina e começa a trabalhar localmente. Ao concluir o desenvolvimento, ele

deve integrar o seu código com o da linha principal do repositório. Mas antes, ele deve dar

build (compilar, preparar um executável, rodar testes automatizados, etc.) em sua

máquina para ver se suas alterações funcionam e passam nos testes. Caso esteja tudo

correto, o desenvolvedor deve se preparar para integrar ao repositório central. Isso inclui

integrar em sua máquina o código atual que está no repositório para verificar se tem

algum conflito causando erro de compilação ou nos testes. Esse passo é importante visto

que, em paralelo, outros desenvolvedores podem ter submetido suas alterações para o

repositório central.

Após realizar os ajustes necessários para a integração funcionar, o desenvolvedor

sincroniza o seu código no repositório central.

Na Integração Contínua, esse processo deve ser feito frequentemente, sendo

sincronizado sempre que possível com o repositório central. O desenvolvedor só deve

considerar o seu trabalho sincronizado quando realizar um build na máquina de

integração com a linha principal do código, e todos os testes sejam executados com

sucesso.

Assim, os problemas são encontrados mais rapidamente, visto que a alteração é

relativamente pequena, sendo mais fácil de identificar a fonte do problema realizando

debug ou comparação das diferenças. Sem contar que as alterações estão mais recentes

na memória, facilitando também retomar a linha de raciocínio para realizar as devidas

correções. Um ambiente de Integração Contínua não deve permanecer com uma versão

falha por muito tempo.


124

O processo de realizar o build em uma máquina de integração e verificar o resultado dos

testes automatizados pode ser realizado manualmente, mas sem dúvida uma ferramenta

é mais eficiente e eficaz.

Apenas compilar o código não é suficiente. É importante que os testes automatizados

sejam executados para identificar um número maior de defeitos. Um build deve falhar

caso algum teste executado automaticamente falhe.

Muitas equipes agendam o build para executado em um determinado horário, como por

exemplo, de madrugada. Segundo Martin Fowler, essa abordagem não é suficiente para

ser considerada Integração Contínua, visto que o objetivo é encontrar os problemas o

quanto antes, e dessa forma os problemas são descobertos após 24 horas.

Para ser frequente, a realização de um build deve ser executada rapidamente. Martin

Fowler argumenta que 10 minutos é um tempo suficiente, e apresenta uma estratégia

para atingir esse objetivo, já que alguns builds podem demorar mais por ter que testar

dados acessando o banco de dados, etc. Ele sugere a utilização de builds em estágios. O

primeiro estágio é o build executado automaticamente quando o desenvolvedor submete

o seu código para a linha principal do projeto no repositório. Esse build tem que prover

feedback rapidamente, portanto ele possui adaptações para atingir esse objetivo, como

por exemplo, realizar mais os testes unitários e deixar os testes mais demorados para o

outro build. Portanto, esse build vai detectar uma quantidade menor de bugs, mas o ponto

é equilibrar de forma que o build seja rápido e confiável o suficiente. O segundo estágio

pode ser realizado em máquinas adicionais, e esse sim realizará todos os testes,

demorando mais tempo para executar, podendo levar algumas horas. Martin Fowler

argumenta que no segundo estágio os problemas podem ser resolvidos nos dias

seguintes. Para realizar os dois estágios várias vezes ao dia, transferindo executáveis

entre máquinas (físicas ou virtuais) é importante que essa tarefa seja feita

automaticamente.

Sempre que possível, é importante que a máquina que executa os builds se localize, o

mais próximo possível do ambiente de produção. Incluindo recursos de hardware,

sistemas operacionais, dentre outros.


125

Para implantar a Integração Contínua, é importante conhecer as recomendações de

Martin Fowler. O primeiro passo é construir um build automático. Mesmo não

considerando um build por dia, Fowler indica que essa pode ser uma boa forma de

começar. Adicionar testes automatizados ao build, se o projeto ainda não os tiver,

começar construindo os testes para as áreas que costumam ser problemáticas.

O ponto principal de realizar a Integração Contínua é reduzir os riscos, sabendo a todo o

momento o que está funcionando. Vale lembrar que os testes não são perfeitos, e

apontam a presença do defeito, e não a sua ausência. Apenas executar a Integração

Contínua, com testes mal elaborados, não vai garantir a qualidade adequada. Entretanto,

a realização dos testes com uma frequência alta tende a apontar os defeitos de forma que

sejam mais fáceis de descobrir. A maior qualidade está relacionada à qualidade dos

testes criados.

Conheça Martin Fowler:

Martin Fowler é um renomado palestrante e autor de artigos e livros, relacionados ao desenvolvimento e testes de software. Trabalhou com Kent Beck no C3 (projeto que Kent gerenciava e onde utilizou os métodos ágeis que culminaram na escrita do livro do XP). Desde 2000 trabalha na ThoughWorks empresa desenvolvedora de ferramentas open-source como o Selenium e o CruiseControl (para Integração Contínua). Possui ampla experiência e bons artigos sobre Integração Contínua,

e por isso foi utilizado como referência para esta unidade. Maiores informações e artigos disponíveis em: http://martinfowler.com. Foto de: Adewale Oshineye.


126

UNIDADE 28

Objetivo: Conhecer algumas funcionalidades de ferramenta para Integração Contínua, visualizando o funcionamento da ferramenta Jenkins

Integração Contínua - Ferramenta Jenkins I

Como explicado na Unidade anterior, a Integração Contínua pode ser realizada

manualmente ou através de ferramentas. A realização manual consiste no desenvolvedor

realizar o build em sua máquina e em seguida, se tudo estiver certo, no repositório

central, executar os testes e acompanhar os resultados. A realização através de

ferramenta automatiza todos esses passos: quando o desenvolvedor sincroniza o seu

projeto com o repositório, a ferramenta gera o build, realiza os devidos testes e

checagens, e informa através de e-mail ou outra forma de comunicação configurada, se o

resultado foi positivo ou negativo. Lembrando que o trabalho do desenvolvedor só é

considerado terminado quando a integração apresenta resultado positivo.

O próprio build pode e deve ser automatizado através de scripts, utilizando ferramentas

como Ant(Java), Maven (Java), Nant (.Net), MSBuild(.Net), etc. Diferentes builds podem

ser necessários (ex: builds em estágios), portanto os scripts devem contemplar cada

caso.

O Jekins (http://jenkins-ci.org/) é uma ferramenta gratuita para

realização de Integração Contínua. É fácil de usar e de instalar. O

arquivo jenkins.war pode ser disponibiliizado de duas formas: em um container Java EE

(ex: Tomcat), ou através da execução direta "java -jar jenkins.war", não sendo necessário

a instalação de um servidor web visto que o Jenkins inicializa um servidor web embutido

(servidor bem pequeno, contém 320 kb), bastando acessar http://localhost:8080/. A

primeira forma é recomendada para o uso real, sendo a segunda para demonstração e

testes da ferramenta. Caso prefira, ao invés do jenkins.war, é possível baixar um


127

instalador nativo para diferentes sistemas operacionais. Para configurar o sistema, clique

em "Gerenciar Jenkins", em seguida em "Configurar Sistema".

Figura 36 – Configurar Jenkins

Ao clicar, é exibida uma tela com diversas configurações. Por exemplo, é possível

configurar em qual JDK(Java Development Kit) o projeto deve rodar. Essa configuração é

opcional, sendo apenas necessária quando o projeto precisa de uma versão específica do

JDK para poder ser compilado e/ou realizar testes. É possível configurar também o Ant ou

Maven para realização dos scripts automáticos, o Subversion ou CVS (ferramenta para

controle de versão), os dados do e-mail, caso deseje receber notificações por e-mail,

dentre outros.


128

A figura a seguir apresenta algumas dessas configurações.

Figura 37 – Tela de Configuração do Jenkins


129

O interessante é que o Jenkins possui integração com diversas ferramentas. Atualmente

são mais de 400 plugins disponíveis para integração, sendo bem fácil de instalar,

bastando clicar no plugin desejado e em "instalar".

Figura 38 – Instalando Plugins

Alguns dos plugins disponíveis são para as ferramentas: JUnit, Emma, Selenium,

Findbugs, Testlink, Checkstyle, etc, ou seja, é possível integrar com algumas ferramentas

gratuitas que foram apresentadas neste módulo.

Assim, quando um desenvolvedor sincroniza o seu código através do CVS ou Subversion,

o Jenkins pode dar o build, gerar e instalar os pacotes, rodar os testes do JUnit,

Selenium,etc em diferentes ambientes, verificar o padrão do código, verificar a cobertura

dos testes, enviar os resultados por e-mail ou RSS, dentre outras atividades pertinentes.

E o melhor, tudo isso de forma automática.


130

O build pode ser configurado para ser realizado sempre em um horário específico, ou

então a cada nova versão sincronizada com o CVS/Subversion.

Até Janeiro de 2011 o nome do Jenkins era Hudson. Portanto, muitas das referências em artigos, revistas, sites, blogs e fóruns estarão com o nome Hudson. Lembre disso quando for realizar uma pesquisa na Web sobre essa incrível ferramenta para Integração Contínua.


131

UNIDADE 29

Objetivo: Conhecer algumas funcionalidades de ferramenta para Integração Contínua, visualizando o funcionamento da ferramenta Jenkins

Integração Contínua - Ferramenta Jenkins II

Utilizando os plugins, é possível utilizar o Jenkins para controlar projetos em Phyton, PHP,

Net, Android, dentre outros, sem mencionar Java que é o padrão da ferramenta.

O Jenkins permite criar builds e testes para serem realizados em diferentes

computadores. Essa facilidade permite acelerar o tempo para execução do build e testes,

uma vez que permite realizar atividades em paralelo. É possível monitorar, através do

Jenkins, informações a respeito dos computadores, como a diferença do relógio, espaço

livre em disco, o sistema operacional utilizado, dentre outros.

Figura 39 – Acompanhando os Computadores (Kawaguchi, 2009)

O painel de controle apresenta o resumo com informações visuais para facilitar a rápida

interpretação, em conjunto com dados sobre o período e tempo da última execução.


132

Figura 40 – Painel de Controle dos Projetos

Na figura anterior, o status azul indica que a última execução foi bem sucedida, enquanto

o amarelo indica instabilidade e o vermelho falha. O ícone com sol indica a estabilidade

do projeto de acordo com as últimas execuções. Quanto mais "ensolarado", mas estável o

projeto. Assim, quando uma das últimas cinco tiver falhado, o ícone parcialmente nublado

é apresentado, quando três das últimas cinco, o ícone totalmente nublado é apresentado,

e assim sucessivamente.

Outro exemplo de informação visual é o gráfico demonstrando o tempo necessário para

realizar cada build, bem como o respectivo status.

Figura 41 – Gráfico com a Tendência dos Builds


133

Ao integrar com ferramentas de cobertura de código como o Emma, é possível visualizar

a porcentagem de cobertura de cada build por blocos, classes, linhas e métodos.

Figura 42 – Gráfico com a Tendência da Cobertura de Código (Austvi,2009)

Outra informação disponibilizada é a tendência

de utilização de espaço em disco. O gráfico

apresenta a quantidade de megabytes

utilizada por cada build e pelo código fonte do

projeto. No gráfico ao lado, no último build, o

consumo foi de 13 MB pelo código e de 806

KB pelo build.


134

É possível visualizar a saída no console contendo o log do erro.

Figura 43 – Log do Console

A próxima figura apresenta a quantidade e informações dos testes executados por

módulo.

Figura 44 – Resultado dos testes


135

A apresentação do Jenkins será finalizada visualizando o gráfico de tendência com o

resultado dos testes sucesso/falha por build.

Figura 45 – Gráfico de Tendência do Resultado dos testes

Os plugins do Jenkins utilizam o próprio Jenkins na Web para Integração Contínua. É possível navegar por esses projetos, e assim conhecer melhor o Jenkins em: . http://ci.jenkins-ci.org/view/All/


136

UNIDADE 30

Objetivo: Relembrar alguns conceitos estudados e apresentar considerações sobre ferramentas

Considerações Finais

Parabéns por completar o estudo do Módulo de Teste de Software!

Vale relembrar alguns conceitos estudados neste Módulo. Foram analisados os níveis de

testes existentes. Apresentado também os custos referentes ao teste de software, o

custo de testar, da falha e o da correção. O custo provocado por uma falha pode ser

intangível, podendo custar milhões de reais, processos judiciais, e até mesmo vidas

humanas. Estudou-se ainda, como a realização dos testes pode proporcionar um retorno

do investimento.

Para poder aumentar a qualidade do software é importante que o teste seja abordado

com um processo próprio, e não mais como uma atividade dentro do processo de

desenvolvimento. Mesmo tendo um processo próprio, o de teste está fortemente

relacionado ao de desenvolvimento.

Ter um processo próprio implica em planejar corretamente o projeto de testes. Um dos

grandes desafios é definir o quanto de teste é adequado e o momento correto de

interromper os testes para liberar o software para produção, de forma a não acontecer:

testes de menos (interrupção muito antes de atingir a cobertura adequada) ou testes em

excesso (custo adicional com os testes não compensa o custo que seria provocado pela

falha). Essa decisão está relacionada à análise de risco do software e à avaliação de

métricas, como por exemplo, quantos testes de alto e médio risco faltam serem

executados, quantos falharam, quantos faltam ser corrigidos, dentre outros.


137

O ambiente de teste engloba a utilização de ferramentas adequadas, a

obtenção/produção da massa de dados necessária para cada tipo de teste e a utilização

de configurações que reproduzam o ambiente de produção.

Quando as condições (exemplo: financeiras) não permitirem alocar uma equipe

independente para realizar os testes, a solução é utilizar a própria equipe de

desenvolvimento para esse fim. Lembrando que o desenvolvedor não deve ser o

responsável por testar o próprio código (com exceção dos testes unitários e alguns testes

de integração).

A fim de evitar desgastes e prejuízos, o planejamento do projeto deve contemplar os

testes de aceitação em todas as etapas e não somente ao final do projeto, submetendo

sempre que possível às telas (mesmo que protótipos) e funcionalidades para aprovação

do cliente.

É importante realizar as revisões e inspeções em documentos e diagramas da análise de

sistemas. Essas revisões devem ser feitas o mais cedo possível e não somente ao final

de cada etapa.

No fechamento do contrato é fundamental negociar prazos e custos adequados que

contemplem a realização dos testes, visto que com as pressões por prazos os testes

tendem a ser a primeira parte a ser reduzida.

Desenvolver testes automatizados pode ser muito útil para garantir a qualidade do

software e facilitar a realização dos testes de regressão, mas é preciso conhecer os

desafios envolvidos, para desenvolvê-los e mantê-los atualizados, para avaliar o custo x

benefícios de cada automatização.

Ferramentas

Foram apresentadas 8 ferramentas gratuitas para: cobertura de código, teste unitário,

objetos "substitutos" (mock objects), gestão de defeitos, gestão do processo de teste,

teste de estresse e de performance, testes de aplicações web e integração contínua.


138

Assim, foi possível perceber os benefícios oferecidos por cada tipo de ferramenta, e como

elas podem ajudar em diferentes etapas e atividades dos testes. Assim como, perceber

também a maturidade de ferramentas gratuitas, eliminando o custo de aquisição, caso

opte por utilizar uma delas.

Vale relembrar algumas considerações feitas pelo Syllabus da certificação ISTQB em

relação aos riscos de utilizar ferramentas: criar expectativas falsas sobre a ferramenta,

subestimar o tempo necessário para iniciar o uso da ferramenta, subestimar o esforço

necessário para manter atualizados os artefatos gerados pelas ferramentas, tentar utilizar

a ferramenta para tudo, mesmo quando a realização manual for mais adequada.

Algumas ferramentas demonstradas; são específicas para linguagem da programação

Java. Uma vez entendido os benefícios oferecidos por determinado tipo de ferramenta

(independente da linguagem de programação) basta pesquisar na internet por uma

ferramenta similar para a sua linguagem de programação preferida. O site

http://www.opensourcetesting.org é um ponto de partida (e não o único), visto que

apresenta diversas ferramentas para diferentes linguagens.

Muitas das ferramentas, se integram com outras, para otimizar ainda mais a gestão e

execução do processo de teste. Abaixo seguem alguns links para demonstrar e servir

como “pontapé inicial” para quem desejar realizar integrações, mas outras integrações

podem ser pesquisadas na Internet:

• TestLink + Mantis: http://sembugs.blogspot.com/2008/06/integrao-do-testlink-com-

o.html

• TestLink + Selenium: http://sembugs.blogspot.com/2010/10/integracao-selenium-e-

testlink.html

• Selenium + Mantis: http://sembugs.blogspot.com/2010/10/integracao-selenium-

mantis.html

• Selenium+Mantis+Testlink: http://sembugs.blogspot.com/2010/10/projeto-

integracao-selenium-mantis.html

• TestLink + Eclipse: http://www.jailtonalkiminlouzada.com/2010/11/integracao-

testlink-e-eclipse/


139

Após estudar este Módulo, quais mudanças você pretende propor em relação aos testes de software na organização em que trabalha (seja ela desenvolvedora de software ou cliente)?

•

TESTE DE SOFTWARE - infobitsolucoes.com de Software... · Apresentar de forma dinâmica e...

Documents

Transcript of TESTE DE SOFTWARE - infobitsolucoes.com de Software... · Apresentar de forma dinâmica e...