introdução a testes de software - unidade i

Curso de Testes Automatizados de SoftwareUnidade IIntrodução

Agenda

● Apresentação● Objetivos● Metodologia● Pré-requisitos● Conteúdo Pragmático● Introdução a teste de software● Introdução a automação de teste de software● Básico sobre teste unitário

Apresentação

● Curso● Testes Automatizados de Software - Introdução e

Desenvolvimento

● Realização● SEPLAG

● Carga horária● 16 horas

● Frequência● 23/01, 24/01, 25/01 e 26/01 de 2012● 08:00 as 12:00

Objetivo

● Demonstrar as tecnologias e boas praticas que envolvem a construção de testes de software.

● Facilitar a construção e melhoramento dos processos de testes de software automatizados.

Metodologia

● O conteúdo da disciplina será desenvolvido por meio de aulas expositivas, exercícios e discussões em sala de aula.

Pré-requisitos

● Conhecimentos em Orientação a Objetos● Conhecimentos em Java● Ambiente de desenvolvimento instalado

(Eclipse 3.x, Jboss Tools 3.x e Maven 2)

Conteúdo Pragmático

● Unidade I

● Introdução a teste de software

● Introdução a automação de teste de software

● Básico sobre teste unitário

● Unidade II

● Técnicas de Teste Unitários

● TestNG

● Mockito

● Unidade III

● Testando com Banco de Dados

● DBUnit

● Testes Funcionais

● Selenium

● Unidade IV

● Princípios e Filosofia de Testes Automatizados

● Introdução ao TDD

Algumas Duvidas

● Testes de Software?● Testes Automatizados?● Por que testar?● Quando preciso testar?● Como testar?

Teste de Software

● Definições● É uma investigação conduzida para fornecer os

interessados informações sobre a qualidade do produto ou serviço em teste.

● Também pode fornecer uma visão objetiva, independente do software para permitir identificar e compreender os riscos na implementação do software.

● Processo de validação e verificação de que um programa de software (aplicativo ou produto).– Cumpre com os requisitos que o orientaram na concepção e

desenvolvimento– Funciona conforme esperado

Quando preciso testar?

● Teste de software, dependendo do método teste empregado pode ser implementados a qualquer momento no processo de desenvolvimento.

● Entretanto, a maioria do esforço de teste ocorre depois que as exigências foram definidas e o processo de codificação foi concluído. Como tal, a metodologia do teste é regido pela metodologia de desenvolvimento de software adotado.

● Diferentes modelos de desenvolvimento focalizam o esforço de teste, em diferentes pontos no processo de desenvolvimento.

Visão geral

● Teste nunca pode identificar completamente todos os defeitos no software

● Em vez disso, ele fornece uma crítica ou comparação que compara o estado e o comportamento do produto contra princípios ou mecanismos pelos quais alguém pode reconhecer um problema.● Ex.: Especificações, contratos, versões anteriores, produtos ou

expectativa do usuário

● Um estudo realizado pelo NIST em 2002 relata que os bugs de software custaram a economia dos EUA, 59,5 bilhões dólares anualmente. Mais de um terço desse custo poderia ser evitado se um melhor teste de software foi realizado

Conceitos importantes

● Escopo● Funcional vs Não-Funcional● Bug e Falha● Combinações de entradas e pré-condições● Verificação e Validação● Garantia de Qualidade de Software (SQA)

Escopo

● "Os testes podem apenas mostrar a presença de erros, não sua ausência", Dijkstra, et al. 1972

● A principal finalidade do teste é detectar falhas de software de modo que os defeitos poção ser descobertos e corrigidos. Teste não pode estabelecer que um produto funciona corretamente em todas as condições, mas só pode demonstrar que ela não funciona adequadamente em condições específicas.

● O escopo dos testes de software, muitas vezes inclui o exame de código, bem como a execução desse código em vários ambientes e condições.

Funcional vs Não-Funcional

● Teste funcional ● Refere-se a atividades que verificar uma ação

específica ou função do código.

● Não-funcionais ● Refere-se a aspectos do software que não pode

estar relacionada a uma função específica ou ação do usuário, tais como escalabilidade, desempenho, comportamento sob certas restrições, ou de segurança.

Bug e Falha

● Geralmente o processo de falhas de software segue o seguinte: ● Um programador faz um erro, o que resulta em um

bug no software de código-fonte . Se este defeito é executado, em certas situações o sistema irá produzir resultados errados, causando uma falha .

Erro → Bug → Falha● Mas, nem todos os defeitos de software são

causados por erros de codificação.

Combinações e Pré-condições

● Um problema fundamental com teste de software é que os testes com todas as combinações e pré-condições (estado inicial) não é viável, mesmo com um simples produto.

● Isto significa que o número de defeitos em um produto de software pode ser muito grande e defeitos que ocorrem com pouca frequência são difíceis de encontrar.

● Mais significativamente os que envolvem requisitos não-funcionais: usabilidade , escalabilidade , desempenho , compatibilidade , confiabilidade.

Verificação e Validação

● Verificação● “Estamos construindo o produto corretamente?”● O software está de acordo com suas

especificações

● Validação● “Estamos construindo o produto corretamente?”● O sistema atende às expectativas do usuário

● As especificações nem sempre estão de acordo com as expectativas dos usuários.

Garantia de Qualidade de Software (SQA)

● Teste de software é uma tarefa destinada a detectar defeitos de software.

● QA (Garantia de qualidade) é implementação de políticas e procedimentos destinados a prevenir a ocorrência de defeitos em primeiro lugar.

● Teste de software faz parte do processo de SQA.

Tipos de Testes de Software

● Testes de Componente● Testes de Unidade

● Testes de Sistema● Testes de Integração● Testes Funcionais● Testes de Carga

● Testes de Aceitação● Testes do cliente

Processos de Testes

● Tradicional CMMI ou Modelo Waterfall● Comumente os testes são realizados por um grupo

independente de testadores após o desenvolvimento da funcionalidade.

● Agile ou Extreme Programing● Nestes processos geralmente adotam o TDD (Test

Driving Development) onde os testes unitários são escritos e primeiro lugar.

Teste de Software

● Motivação● Garantir software que funciona conforme

especificado e que atenda as expectativas do usuário

● Ocorrência de falhas humanas no processo de desenvolvimento é considerável

● Os custos na correção de falhas, justificam um processo de testes cuidadoso e bem planejado

Teste de Software

● Finalidade ● Averiguar se todos os requisitos foram

corretamente implementados● Assegurar qualidade e corretude do software● Reduzir custos de manutenção corretiva e

retrabalho.

● Testar é a maneira de obter feedback do software. Por estão razão é um elemento essencial no desenvolvimento “ágil” e “limpo”.

O que é Testar?

Visão Tradicional de Testes

● N° de Bugs determina a qualidade do software

Teste de Desenvolvedores

● Frist time, every time

Testes Automatizados

Testes Automatizados

● Todos buscam automatizar os testes principalmente com objetivo de evitar retrabalho e reduzir custos. Mas recentemente a experiência de muitos Testadores e Gerente de Testes com ferramentas de automação, os deixaram menos que satisfeito. A causa é os autos custos de Manutenção devido ao problema de "Fragile Test".

Fragile Test

● Testes automatizados usando ferramentas "recod and playback" ou "robot user", vem ganhado uma reputação ruim pelos seu primeiros usuários por não conhecerem suas limitações, são elas:● Sensibilidade de comportamento● Sensibilidade de interface● Sensibilidade de dados● Sensibilidade de contexto

Sensibilidade de Comportamento

● Se determinada funcionalidade for alterado, provavelmente todos os testes desta funcionalidade iram falhar

Sensibilidade de interface

● Testar logica de negocio via usuário de interface é uma má ideia!

● Mesmo pequenas mudanças na interface podem fazer os testes falhar

Sensibilidade dos Dados

● Todo teste assume um estado inicial dos dados, se e teste sofrem ao menos uma pequena alteração, os testes podem falhar.

● Manter os testes imune as dados requer um grade esforço.

Sensibilidade do Contexto

● O comportamento ou estado de coisas fora do sistema, podem afetar o seu comportamento e consequentemente ocasionar falha nos testes.

É Fato

● As quatro sensibilidades existem, independentemente de qual tecnologia que usamos para automatizar os testes. Claro, algumas tecnologias podem nos dar maneiras de contornar esses problema, enquanto outros nos força para um caminho particular. A família xUnit (Junit, TestNG, ...) nos dá um grande grau de controle, só temos de aprender como usá-lo efetivamente.

Automação de Testes

● Muito se fala sobre testes automatizados de unidade e aceitação como parte do desenvolvimento ágil de software

● Escrever bons testes de código é difícil, e mantelos limpo e claro é mais difícil ainda.

● O Principal causa disso é o fato de ser opcional ( o cliente não paga por isso) e com o tempo os teste vão sendo abandonados devido ao aumento de complexidade e/ou custo de manutenção.

Custos

● O custo de escrever e manter conjuntos de testes tem sido um desafio particular.

Soluções

● Mas felizmente, muitas equipes tem desenvolvido soluções que ajudam a enfrentar esses desafios.

Economia com Automação de Testes

● Evidente, que sempre há custos construção e manutenção de uma suíte de testes.

● Nosso objetivo deve ser o de tomar a decisão de fazer a automação de testes assegurando o não aumento nos custos de desenvolvimento de software.

● Assim, o custo adicional de construção e manutenção de testes automatizados devem ser compensados com a redução na depuração/resolução de problemas diminuindo os custos de remediação dos defeitos que possam ter passado despercebidos até a fase de teste formal do projeto ou uso de produção.

● A figura 1.0 mostra como o custo da automação é compensado pelos benefícios recebidos.

Economia com Automação de Testes

Figura 1.0 - Um projeto de teste unitários automatizado com um bom retorno sobre o investimento. O custo-benefício quanto ao custo total é reduzido por boas práticas de teste.

Economia com Automação de Testes

● Devemos ressaltar que, se os testes são difíceis de escrever, são difíceis de compreender, e necessitam de manutenção frequente, o custo total de desenvolvimento é caro.

● E os benefícios podem não equilibrar o esforço despendido para manter os testes automatizados, a figura 1.1 demostra isso.

Economia com Automação de Testes

Figura 1.1 Um projeto de teste unitário automatizado com um baixo retorno do investmeno e custo-benefício quanto ao custo total é aumentada por práticas de teste pobres.

Teste Automatizados

● Objetivos para atingir a economia esperada:● Os testes devem nos ajudar a melhorar a

qualidade.● Os testes devem nos ajudar a entender o SUT

(system under test).● Os testes devem reduzir (e não introduzir) riscos.● Os testes devem ser fáceis de executar.● Os testes devem ser fáceis de escrever e manter.● Os testes devem requerer o mínimo de

manutenção.

Os testes devem nos ajudar a melhorar a qualidade.

● A razão tradicional para testarmos é garantir qualidade (QA). Procuramos responder as seguintes perguntas: O software é feito corretamente? O software faz a coisa certa?

● Como:● Testes como especificação● Prevenir Bugs● Localizar defeitos

Os testes devem nos ajudar a entender o SUT

● Os teste podem mostrar como o código deve funcionar.

● Como:● Testes como documentação

– Sem testes automatizados temos que estudar o código tetando responder à pergunta: “Qual deve ser o resultado se …?”

– Se quisermos saber como o sistema faz alguma coisa, só precisamos executar os teste especifico e depurar se necessário

Os testes devem reduzir (e não introduzir) riscos.

● Testes devem melhorar a qualidade do nosso software, ajuda-nos a documentar melhor os requisitos e evitar lentidão no desenvolvimento incremental. Esta é certamente uma forma de redução de riscos.

● Outra forma de ajudar é verificar comportamento em situações que não podem ser identificada nos testes de caixa preta.

● Como:● Testes como Rede de Segurança● Não causar danos

– Mantenha a logica de produção fora do código de produção

Os testes devem ser fáceis de executar

● O que torna fácil de executar testes? Quatro objetivos específicos respondem a esta pergunta:● Testes devem ser totalmente automatizado para que eles

possam ser executados sem qualquer esforço.● Testes devem ser auto-verificáveis para que eles possam

detectar e relatar quaisquer erros sem inspeção manual.● Testes devem ser repetíveis para que eles possam ser

executados várias vezes com o mesmo resultado.● Idealmente, cada teste deve ser um teste independente que

pode ser executado por si só.

● O feedback deve está a um clique de distância

Os testes devem ser fáceis de escrever e manter

● Testes de tornar-se complicada por duas razões:● Tentamos verificar muitas funcionalidades em um único teste.● Existem um “gap de expressividade” muito grande entre a

linguagem de testes (ex. Java) e as relações e conceitos do domínio que estamos tentando expressar no teste.

● Como:● Testes simples

– Uma condição para verificar por teste

● Testes expressivos● Separação de interesses

Devem requerer o mínimo de manutenção.

● A mudança é um fato da vida. E na verdade escrevemos software para facilitar as mudanças.

● Sistema evolui em torno dos testes● Como:

● Testes robustos

Projeto Construção de Testes

Testes como Especificação Total automatização

Testes como Documentação Alto verificação

Testes como Rede de Segurança Teste que se pode repetir

Localizador de Defeitos Tete Robusto

Fácil de escrever ou manter Teste Simples

Prover Qualidade Teste Expressivo

Reduzir risco Separação de interesses

Prevenir Bug Não cause danos

Testes Automatizados – Metas

Básico de Testes Unitários

● Definindo Testes Unitários● Explorando um simples exemplo● Um pouco de TDD

Definição

● Testes Unitários não é um conceito novo em desenvolvimento de software

● Kent Beck itroduzio o conceito de teste uninitario em Samalltalk.

● Um teste de unidade é um pedaço de um código (normalmente um método) que invoca uma outra pedaço de código e verifica a veracidade de alguns pressupostos pós-ala. Se os pressupostos vir a ser errado, o teste de unidade falhou. A "unidade" é um método ou função.

Definição

● A importância de escrever bons testes unitários● Todos nos já escrevemos testes unitários

Definição

● Em testes clássicos, os desenvolvedores usam uma GUI (graphical user interface) para desencadear uma ação sobre a classe que eles querem para testar. Em seguida, verificam os resultados.

Propriedades de um “bom” teste unitário

● Um teste unitário deve ter as seguintes propriedades:● Deve ser automatizados e repetíveis.● Deve ser fácil de implementar.● Uma vez que é escrito, ele deve permanecer para

uso futuro.● Deve funcionar com o pressionar de um botão.● Deve funcionar rapidamente.

Propriedades de um “bom” teste unitário

● Muitas pessoas confundem ato de testar software com o conceito de teste unitário Então pergunte a si mesmo sobre os testes que escreveu até agora:● Posso executar e obter resultados de um teste de unidade que eu escrevi duas semanas

ou meses ou anos atrás?

● Qualquer membro de minha equipe pode executar e obter os resultados dos testes que eu escrevi há dois meses?

● Posso executar todos os testes unitários que eu escrevi em não mais do que alguns minutos?

● Posso executar todos os testes unitários que eu escrevi com um botão?

● Posso escrever um teste unitário básico em não mais do que alguns minutos?

● Se você respondeu “Não” a alguma das questões acima, provavelmente você não está implementando testes unitários É algum outro tipo de teste tão importante quanto os testes unitários

Diferenças

● Você pode perguntar, “O que eu estava fazendo até agora?”. Provavelmente testes de integração

● Exite uma grande duvida sobre a diferença de testes unitários e testes de integração

Testes de Integração

● Teste de integração consiste em testar dois ou mais módulos de softwares como um grupo.

Bom Teste Unitário

● A definição● Um teste unitário é uma parte automatizada de

código que chama o método ou classe que está sendo testado e, em seguida, verifica algumas suposições sobre a lógica e comportamento desse método ou classe. Um teste de unidade é quase sempre escrito usando uma estrutura de testes unitário Pode ser escrito de forma fácil e executa rapidamente. É totalmente automatizado, confiável, legível e de fácil manutenção.

Um teste unitário simples

● É possível escrever teste unitário automatizado sem usar um framework de teste.

SUT

Classe de Teste

Executando o Teste

Melhorando um pouco

Melhorando um pouco

Primeiro teste unitário

● Frameworks de testes unitários (xUnit)● Escrevendo o primeiro teste unitário com Junit● Trabalhando com atributos do Junit● Compreendendo o estado dos testes

Frameworks para testes unitários● O frameworks de testes oferecem facilidades

semelhantes ao que as IDEs nós proporcionam

Pratica de teste unitário Como o framework ajuda

Escrever testes facilmente e de forma estruturada.

Fornece ao desenvolvedor uma biblioteca com:• Classes ou interfaces para herdar.• Atributos para colocar em seu código para observar seus testespara ser executado.• Classes de acessão que possuem métodos especiais que você invoca para verificar seu código.

Execute um ou todos os testes de unidade.

- Quadro prevê um console ou Ferramenta GUI que:• Identifica os testes em seu código.• Executa testes automaticamente.• Indica o estado durante a execução.• Pode ser automatizada por linha de comando.

Como os frameworks ajudam.

Pratica de teste unitário Como o framework ajuda

Analisar os resultados do teste é executado.

Os consoles geralmente fornecem informações, tal como:• quantos testes correu.• quantos testes não foi executada.• quantos testes falharam.• quais testes falharam.• os testes de razão, não.• A mensagens de assert que você escreveu• o local de código que falhou.• possivelmente um rastreamento de pilha completa de todas as exceções que fez com que o teste falhar.

Como os frameworks ajudam.

xUnit

● CppUnit para C++● JUnit para Java● Nunit para .Net● HUnit para Haskell● …

Projeto LogAn

● Uma determinada empresa possui um vários sistemas que geram logs num formato privado. Estes logs devem ser lidos e determinados comportamentos identificados e notificados aos resposaveis.

● Para resolver este problema daremos inicio ao projeto LogAn que começara bem simples.

Junit 4

● O JUnit (junit.org) é um framework muito simples para facilitar a criação destes testes unitários e em especial sua execução. Ele possui alguns métodos que tornam seu código de teste bem legível e fácil de fazer as asserções.

● Uma asserção é uma afirmação: alguma invariante que em determinado ponto de execução você quer garantir que é verdadeira. Se aquilo não for verdade, o teste deve indicar uma falha, a ser reportada para o programador, indicando um possível bug.

● Escrito originalmente por Kent Beck (Extreme

Programming) e Erich Gamma (Design Patterns)

Junit API

● Principais Anotações● @Test – Marca uma classe ou metodo como sendo

parte de um teste.● @BeforeClass – Executa um método antes da classe

iniciar● @AfterClass – Executa um metodo depois da classe

iniciar● @Before – Executa um método antes de qualquer

metodo de teste● @After – Executa um método depois de qualquer

metodo de teste.

Junit API Resumida

Exercícios

Referências

● Osherove, Roy. The art of unit testing : with examples in .NET. 2009

● Meszaros, Gerard. XUnit test patterns : refactoring test code. 2007

● http://en.wikipedia.org/wiki/Software_testing