SlideShare uma empresa Scribd logo
Curso de Testes Automatizados de Software
                Unidade I
               Introduçã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.
O que é Testar?
●Testar é a maneira de obter feedback do software. Por estão razão é
um elemento essencial no desenvolvimento “ágil” e “limpo”.
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
Testes Automatizados – Metas
                   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
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
Como os frameworks ajudam.
    Pratica de teste unitário              Como o framework ajuda
Escrever testes facilmente e     Fornece ao desenvolvedor uma
de forma estruturada.            biblioteca com:
                                 • Classes ou interfaces para herdar.
                                 • Atributos para colocar em seu código
                                 para observar seus testes
                                 para 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 - Quadro prevê um console ou Ferramenta GUI
                              que:
de unidade.                   • 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 é   Os consoles geralmente fornecem
executado.                          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.
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

Mais conteúdo relacionado

Mais procurados

Teste de Software - Introdução
Teste de Software - IntroduçãoTeste de Software - Introdução
Teste de Software - Introdução
Joeldson Costa Damasceno
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
Tiago Antônio da Silva
 
Especificação de Requisitos de Software
Especificação de Requisitos de SoftwareEspecificação de Requisitos de Software
Especificação de Requisitos de Software
Ralph Rassweiler
 
Exemplo de Plano de testes
Exemplo de Plano de testes Exemplo de Plano de testes
Exemplo de Plano de testes
Leandro Rodrigues
 
Planejamento de Testes
Planejamento de TestesPlanejamento de Testes
Planejamento de Testes
elliando dias
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de software
Rondinelli Mesquita
 
Introdução a Testes Automatizados
Introdução a Testes AutomatizadosIntrodução a Testes Automatizados
Introdução a Testes Automatizados
elliando dias
 
Qualidade de Software: Modelos e normas
Qualidade de Software: Modelos e normasQualidade de Software: Modelos e normas
Qualidade de Software: Modelos e normas
Alex Camargo
 
Linguagem de programação
Linguagem de programação Linguagem de programação
Linguagem de programação
Marcos Gregorio
 
Introdução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem práticaIntrodução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem prática
Fabrício Campos
 
Verificação, Validação e Teste de Software
Verificação, Validação e Teste de SoftwareVerificação, Validação e Teste de Software
Verificação, Validação e Teste de Software
Camilo Almendra
 
Modelo de Prototipação
Modelo de PrototipaçãoModelo de Prototipação
Modelo de Prototipação
Juliano Pires
 
Teste de software
Teste de softwareTeste de software
Teste de software
Rafael Sanches
 
Diagramas de casos de uso - aula 2
Diagramas de casos de uso - aula 2Diagramas de casos de uso - aula 2
Diagramas de casos de uso - aula 2
Franklin Matos Correia
 
Normas e Padrões para a Qualidade de Software
Normas e Padrões para a Qualidade de SoftwareNormas e Padrões para a Qualidade de Software
Normas e Padrões para a Qualidade de Software
Danilo Sousa
 
Prototipagem
PrototipagemPrototipagem
Prototipagem
jwainer
 
Introdução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de SoftwareIntrodução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de Software
Daniel Cukier
 
IHM x IHM – INTERFACE x INTERAçÃO HOMEM-MÁQUINA
IHM x IHM – INTERFACE x INTERAçÃO HOMEM-MÁQUINAIHM x IHM – INTERFACE x INTERAçÃO HOMEM-MÁQUINA
IHM x IHM – INTERFACE x INTERAçÃO HOMEM-MÁQUINA
Diego BBahia
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
Leinylson Fontinele
 
Introdução a Gerência de Configuração
Introdução a Gerência de ConfiguraçãoIntrodução a Gerência de Configuração
Introdução a Gerência de Configuração
Igor Takenami
 

Mais procurados (20)

Teste de Software - Introdução
Teste de Software - IntroduçãoTeste de Software - Introdução
Teste de Software - Introdução
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
 
Especificação de Requisitos de Software
Especificação de Requisitos de SoftwareEspecificação de Requisitos de Software
Especificação de Requisitos de Software
 
Exemplo de Plano de testes
Exemplo de Plano de testes Exemplo de Plano de testes
Exemplo de Plano de testes
 
Planejamento de Testes
Planejamento de TestesPlanejamento de Testes
Planejamento de Testes
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de software
 
Introdução a Testes Automatizados
Introdução a Testes AutomatizadosIntrodução a Testes Automatizados
Introdução a Testes Automatizados
 
Qualidade de Software: Modelos e normas
Qualidade de Software: Modelos e normasQualidade de Software: Modelos e normas
Qualidade de Software: Modelos e normas
 
Linguagem de programação
Linguagem de programação Linguagem de programação
Linguagem de programação
 
Introdução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem práticaIntrodução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem prática
 
Verificação, Validação e Teste de Software
Verificação, Validação e Teste de SoftwareVerificação, Validação e Teste de Software
Verificação, Validação e Teste de Software
 
Modelo de Prototipação
Modelo de PrototipaçãoModelo de Prototipação
Modelo de Prototipação
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
Diagramas de casos de uso - aula 2
Diagramas de casos de uso - aula 2Diagramas de casos de uso - aula 2
Diagramas de casos de uso - aula 2
 
Normas e Padrões para a Qualidade de Software
Normas e Padrões para a Qualidade de SoftwareNormas e Padrões para a Qualidade de Software
Normas e Padrões para a Qualidade de Software
 
Prototipagem
PrototipagemPrototipagem
Prototipagem
 
Introdução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de SoftwareIntrodução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de Software
 
IHM x IHM – INTERFACE x INTERAçÃO HOMEM-MÁQUINA
IHM x IHM – INTERFACE x INTERAçÃO HOMEM-MÁQUINAIHM x IHM – INTERFACE x INTERAçÃO HOMEM-MÁQUINA
IHM x IHM – INTERFACE x INTERAçÃO HOMEM-MÁQUINA
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
 
Introdução a Gerência de Configuração
Introdução a Gerência de ConfiguraçãoIntrodução a Gerência de Configuração
Introdução a Gerência de Configuração
 

Semelhante a Introdução a Testes de Software - Unidade I

Testes Funcionais - Unidade IV
Testes Funcionais - Unidade IVTestes Funcionais - Unidade IV
Testes Funcionais - Unidade IV
João Lourenço
 
Gerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxGerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptx
Roberto Nunes
 
Aula - Teste de Software
Aula - Teste de SoftwareAula - Teste de Software
Aula - Teste de Software
Mauricio Cesar Santos da Purificação
 
Qualidade de Software - Desenvolvimento dirigido por testes
Qualidade de Software - Desenvolvimento dirigido por testesQualidade de Software - Desenvolvimento dirigido por testes
Qualidade de Software - Desenvolvimento dirigido por testes
Joaquim Lopes Júnior
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
Roberto Espinha
 
Palestra Fundamentos de Testes - Tche linux POA
Palestra Fundamentos de Testes  - Tche linux POAPalestra Fundamentos de Testes  - Tche linux POA
Palestra Fundamentos de Testes - Tche linux POA
Aline Zanin
 
Introdução à Engenharia de Testes de Software
Introdução à Engenharia de Testes de SoftwareIntrodução à Engenharia de Testes de Software
Introdução à Engenharia de Testes de Software
Cloves da Rocha
 
Eng de testes
Eng de testesEng de testes
Eng de testes
GrupoAlves - professor
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
testedesoftwarepe
 
Visão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOKVisão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOK
Mário Pravato Junior
 
Palestra Teste de Software: princípios, ferramentas e carreira
Palestra Teste de Software: princípios, ferramentas e carreiraPalestra Teste de Software: princípios, ferramentas e carreira
Palestra Teste de Software: princípios, ferramentas e carreira
Taís Dall'Oca
 
Teste de software - Processo de Verificação e Validação
Teste de software - Processo de Verificação e ValidaçãoTeste de software - Processo de Verificação e Validação
Teste de software - Processo de Verificação e Validação
Joeldson Costa Damasceno
 
Introdução a testes de sofwtare
Introdução a testes de sofwtareIntrodução a testes de sofwtare
Introdução a testes de sofwtare
Fernando Palma
 
Teste de software
Teste de softwareTeste de software
Teste de software
Claudio Eckert
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
Otavio Augusto
 
TesteDeSoftware_WorkshopSINFO2014.pdf
TesteDeSoftware_WorkshopSINFO2014.pdfTesteDeSoftware_WorkshopSINFO2014.pdf
TesteDeSoftware_WorkshopSINFO2014.pdf
Bruno Zolotareff dos Santos
 
Engenharia de Testes
Engenharia de TestesEngenharia de Testes
Engenharia de Testes
UFPA
 
SLIDEPRELIMINAR.pptx
SLIDEPRELIMINAR.pptxSLIDEPRELIMINAR.pptx
SLIDEPRELIMINAR.pptx
GustavoRondini
 
Testes com JUnit
Testes com JUnitTestes com JUnit
Testes com JUnit
JugVale
 
Aula09_TesteSoftware_Parte1_apremdeeghku
Aula09_TesteSoftware_Parte1_apremdeeghkuAula09_TesteSoftware_Parte1_apremdeeghku
Aula09_TesteSoftware_Parte1_apremdeeghku
MoniqueEstevo2
 

Semelhante a Introdução a Testes de Software - Unidade I (20)

Testes Funcionais - Unidade IV
Testes Funcionais - Unidade IVTestes Funcionais - Unidade IV
Testes Funcionais - Unidade IV
 
Gerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxGerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptx
 
Aula - Teste de Software
Aula - Teste de SoftwareAula - Teste de Software
Aula - Teste de Software
 
Qualidade de Software - Desenvolvimento dirigido por testes
Qualidade de Software - Desenvolvimento dirigido por testesQualidade de Software - Desenvolvimento dirigido por testes
Qualidade de Software - Desenvolvimento dirigido por testes
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
 
Palestra Fundamentos de Testes - Tche linux POA
Palestra Fundamentos de Testes  - Tche linux POAPalestra Fundamentos de Testes  - Tche linux POA
Palestra Fundamentos de Testes - Tche linux POA
 
Introdução à Engenharia de Testes de Software
Introdução à Engenharia de Testes de SoftwareIntrodução à Engenharia de Testes de Software
Introdução à Engenharia de Testes de Software
 
Eng de testes
Eng de testesEng de testes
Eng de testes
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
 
Visão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOKVisão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOK
 
Palestra Teste de Software: princípios, ferramentas e carreira
Palestra Teste de Software: princípios, ferramentas e carreiraPalestra Teste de Software: princípios, ferramentas e carreira
Palestra Teste de Software: princípios, ferramentas e carreira
 
Teste de software - Processo de Verificação e Validação
Teste de software - Processo de Verificação e ValidaçãoTeste de software - Processo de Verificação e Validação
Teste de software - Processo de Verificação e Validação
 
Introdução a testes de sofwtare
Introdução a testes de sofwtareIntrodução a testes de sofwtare
Introdução a testes de sofwtare
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
 
TesteDeSoftware_WorkshopSINFO2014.pdf
TesteDeSoftware_WorkshopSINFO2014.pdfTesteDeSoftware_WorkshopSINFO2014.pdf
TesteDeSoftware_WorkshopSINFO2014.pdf
 
Engenharia de Testes
Engenharia de TestesEngenharia de Testes
Engenharia de Testes
 
SLIDEPRELIMINAR.pptx
SLIDEPRELIMINAR.pptxSLIDEPRELIMINAR.pptx
SLIDEPRELIMINAR.pptx
 
Testes com JUnit
Testes com JUnitTestes com JUnit
Testes com JUnit
 
Aula09_TesteSoftware_Parte1_apremdeeghku
Aula09_TesteSoftware_Parte1_apremdeeghkuAula09_TesteSoftware_Parte1_apremdeeghku
Aula09_TesteSoftware_Parte1_apremdeeghku
 

Introdução a Testes de Software - Unidade I

  • 1. Curso de Testes Automatizados de Software Unidade I Introdução
  • 2. 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
  • 3. 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
  • 4. 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.
  • 5. Metodologia ● O conteúdo da disciplina será desenvolvido por meio de aulas expositivas, exercícios e discussões em sala de aula.
  • 6. 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)
  • 7. 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
  • 8. Algumas Duvidas ● Testes de Software? ● Testes Automatizados? ● Por que testar? ● Quando preciso testar? ● Como testar?
  • 9. 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
  • 10. 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.
  • 11. 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
  • 12. 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)
  • 13. 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.
  • 14. 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.
  • 15. 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.
  • 16. 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.
  • 17. 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.
  • 18. 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.
  • 19. 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
  • 20. 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.
  • 21. 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
  • 22. 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.
  • 23. O que é Testar? ●Testar é a maneira de obter feedback do software. Por estão razão é um elemento essencial no desenvolvimento “ágil” e “limpo”.
  • 24. Visão Tradicional de Testes ● N° de Bugs determina a qualidade do software
  • 25. Teste de Desenvolvedores ● Frist time, every time
  • 27. 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".
  • 28. 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
  • 29. Sensibilidade de Comportamento ● Se determinada funcionalidade for alterado, provavelmente todos os testes desta funcionalidade iram falhar
  • 30. 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
  • 31. 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.
  • 32. Sensibilidade do Contexto ● O comportamento ou estado de coisas fora do sistema, podem afetar o seu comportamento e consequentemente ocasionar falha nos testes.
  • 33. É 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.
  • 34. 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.
  • 35. Custos ● O custo de escrever e manter conjuntos de testes tem sido um desafio particular.
  • 36. Soluções ● Mas felizmente, muitas equipes tem desenvolvido soluções que ajudam a enfrentar esses desafios.
  • 37. 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.
  • 38. 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.
  • 39. 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.
  • 40. 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.
  • 41. 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.
  • 42. 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
  • 43. 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
  • 44. 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
  • 45. 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
  • 46. 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
  • 47. 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
  • 48. Testes Automatizados – Metas 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
  • 49.
  • 50. Básico de Testes Unitários ● Definindo Testes Unitários ● Explorando um simples exemplo ● Um pouco de TDD
  • 51. 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.
  • 52. Definição ● A importância de escrever bons testes unitários ● Todos nos já escrevemos testes unitários
  • 53. 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.
  • 54. 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.
  • 55. 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
  • 56. 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
  • 57. Testes de Integração ● Teste de integração consiste em testar dois ou mais módulos de softwares como um grupo.
  • 58. 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.
  • 59. Um teste unitário simples ● É possível escrever teste unitário automatizado sem usar um framework de teste.
  • 60. SUT
  • 65. 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
  • 66. Frameworks para testes unitários ● O frameworks de testes oferecem facilidades semelhantes ao que as IDEs nós proporcionam
  • 67. Como os frameworks ajudam. Pratica de teste unitário Como o framework ajuda Escrever testes facilmente e Fornece ao desenvolvedor uma de forma estruturada. biblioteca com: • Classes ou interfaces para herdar. • Atributos para colocar em seu código para observar seus testes para 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 - Quadro prevê um console ou Ferramenta GUI que: de unidade. • Identifica os testes em seu código. • Executa testes automaticamente. • Indica o estado durante a execução. • Pode ser automatizada por linha de comando.
  • 68. Como os frameworks ajudam. Pratica de teste unitário Como o framework ajuda Analisar os resultados do teste é Os consoles geralmente fornecem executado. 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.
  • 69. xUnit ● CppUnit para C++ ● JUnit para Java ● Nunit para .Net ● HUnit para Haskell ● …
  • 70. 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.
  • 71. 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)
  • 72. 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.
  • 75.
  • 76. 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