SlideShare uma empresa Scribd logo
Validação de Software



                           Professor Manoel Mendonça




Validação de Software – Módulo 1 Conceitos Básicos     Transparência 1
Sobre a Disciplina




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 2
Técnicas para Avaliação da
                   Qualidade de Produtos

         Testes
         Revisões
         Provas Formais




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 3
Instrutor

 • Manoel Mendonça
      –   Sala IM 215
      –   Tel. 3283-6343
      –   Horário para alunos – quarta à tarde
      –   manoel.mendonca@ufba.br




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 4
Site da Disciplina

 • ...




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 5
Bibliografia
 A Practitioner's Guide to Software Test Design by Lee
   Copeland ISBN:158053791x
 Artech House © 2004

 http://www.opensourcetesting.org




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 6
Avaliações

 • Trabalhos, dois trabalhos
 • Provas, uma ou duas




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 7
Plataforma de Trabalho

 • Java e Eclipse
 • JUnit
 • Outras ferramentas




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 8
0. Conceitos Básicos




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 9
0.1 Defeitos e Falhas

 • Defeito
      – um problema nos requisitos, no projeto, no código,
        na documentação ou nos casos de teste
 • Falha
      – um problema no funcionamento do sistema


                 Falha: conseqüência de um defeito



Validação de Software – Módulo 1 Conceitos Básicos   Transparência 10
Defeitos e Falhas: Uma Visão Mais Completa

    Engano (mistake) => “erro” cometido “cabeça” do eng. de
                       software

    Defeito (fault) => “erro” inserido no software


    Erro (error) => “execução” do “erro” conduzindo a um estado
                    incorreto do software

    Falha (failure) => manifestação externa do “erro”


Validação de Software – Módulo 1 Conceitos Básicos      Transparência 11
Principais Artefatos de Software
                     Uma Visão Simplificada




                Especificação             Projeto    Código
                de requisitos



                 Defeitos ocorrem em todos eles !!!


Validação de Software – Módulo 1 Conceitos Básicos            Transparência 12
Defeitos Introduzidos ao Longo do Processo de
                  Desenvolvimento

    • A maior parte é de origem humana.
    • São gerados na comunicação e na transformação de
      informações.
    • Permanecem presentes nos diversos produtos de
      software produzidos e liberados.
    • A maioria encontra-se em partes do produto de
      software raramente utilizadas e/ou executadas.




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 13
0.2 Alguns Tipos de Defeitos Introduzidos

   Tipo de                                   Descrição Geral
   Defeito
Omissão            Informação necessária do sistema foi omitida do artefato de
                   software.
Fato Incorreto     Alguma informação no artefato de software contradiz
                   informação do documento de outra informação no artefato de
                   software.
Inconsistência     Informação contida em uma parte do artefato de software está
                   inconsistente com outra informação no artefato de software.
Ambigüidade        Informação contida no artefato de software é ambígua, isto é,
                   várias interpretações podem ser derivadas da definição levando
                   o desenvolvedor à implementação correta.
Informação         Informação que é fornecida e não é necessária ou nunca
Estranha           utilizada


Validação de Software – Módulo 1 Conceitos Básicos                     Transparência 14
Tipos de Defeitos Introduzidos
                                                                         Copyright Guilherme Travassos
                                                           COPPE/UFRJ – 2003 - http://www.cos.ufrj.br/~ght
             De onde os defeitos vêm?
   Que defeitos podemos encontrar?


                                                                      Outro
                                                                     Domínio
              Conhecimento do
                  domínio

                Requisitos
                                          Fato incorreto
                 Gerais                                                  Informação
                                                                          estranha


                                         Artefatos de
                       Omissão            Software


                                  Inconsistência
                                                                  Ambigüidade



Validação de Software – Módulo 1 Conceitos Básicos                                   Transparência 15
Defeitos Introduzidos ao Longo do Processo
                  de Desenvolvimento

    • Principal causa:
       • tradução incorreta de informações.

    • Quanto antes a presença do defeito for revelada,
      menor o custo de correção do defeito e maior a
      probabilidade de corrigi-lo corretamente.

    • Solução:
          • Introduzir atividades de V V & T ao longo de
            todo o ciclo de desenvolvimento.

Validação de Software – Módulo 1 Conceitos Básicos   Transparência 16
0.3 Verificação e Validação (V&V)

      As atividades de avaliação de produtos são parte do tema
      chamado Verificação e Validação (V&V).


      A definição de V&V abrange muitas das atividades às quais
      nos referimos como Garantia da Qualidade de Software
      (SQA).




Validação de Software – Módulo 1 Conceitos Básicos     Transparência 17
Verificação


       refere-se ao conjunto de atividades que garante que o
    software implementa corretamente uma função específica.
                    “Estamos construindo certo o produto?”




Validação de Software – Módulo 1 Conceitos Básicos           Transparência 18
Validação

      refere-se ao conjunto de atividades que garante que o
  software que foi construído é “rastreável” às exigências do
  cliente.
                   “Estamos construindo o produto certo?”




Validação de Software – Módulo 1 Conceitos Básicos          Transparência 19
0.4 Garantia da Qualidade de Software

      – Métodos de Engenharia de Software: proporcionam a base
      a partir da qual a qualidade é construída.
      – Revisões Técnicas Formais: ajudam a garantir a qualidade
      do produto produzido como uma conseqüência de cada passo
      da engenharia de software.
      – Medição: ajudam a controlar cada elemento da
      configuração de software.




Validação de Software – Módulo 1 Conceitos Básicos       Transparência 20
Garantia da Qualidade de Software (cont.)

     – Padrões e Procedimentos: ajudam a garantir a uniformidade.
     – Garantia de Qualidade de Software (SQA): põe em prática
     uma filosofia de qualidade total.
     – Teste: a qualidade pode ser avaliada.




Validação de Software – Módulo 1 Conceitos Básicos      Transparência 21
Validação de Software – Módulo 1 Conceitos Básicos   Transparência 22
Teste de Software




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 23
Teste

         1 Introdução
         2 Contexto
         3 Organização para Realização de Testes
         4 Executando Teste
         5 Depurando Software
         6 Técnicas de Teste




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 24
1. Introdução

         1.1 Engenharia de Software e Teste
         1.2 O quê é teste
         1.3 Objetivos da Atividade de Teste
         1.4 Erros e as atividades de teste




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 25
1.1 Engenharia de Software e Teste

     1- Fase de Definição ("o que")
           - Análise do sistema
           - Planejamento do projeto de software
           - Análise de requisitos
     2- Fase de Desenvolvimento ("como")
           - Projeto de software
           - Codificação
           - Realização de testes
     3- Fase de Manutenção ("alterações")



Validação de Software – Módulo 1 Conceitos Básicos   Transparência 26
1.2 O Quê é Teste

      1. a atividade de teste é o processo de executar um programa
         com a intenção de descobrir um erro


      2. um bom caso de teste é aquele que tem uma elevada
        probabilidade de revelar um erro ainda não descoberto


      3. um teste bem-sucedido é aquele que revela um erro ainda
         não descoberto.



Validação de Software – Módulo 1 Conceitos Básicos         Transparência 27
1.3 Objetivos da Atividade de Teste

   Objetivo: projetar testes que descubram sistematicamente
   diferentes classes de erros e façam-no com uma quantidade de
   tempo e esforço razoável.
   Se a atividade de teste for conduzida com sucesso, ela
   descobrirá erros no software.
   • A atividade de teste não pode mostrar a ausência de bugs.
   • Ela só pode mostrar se defeitos de software estão presentes.




Validação de Software – Módulo 1 Conceitos Básicos          Transparência 28
1.4 Erros e as Atividades de Teste

       Se erros graves forem encontrados com regularidade,
       isto implica que a qualidade e a confiabilidade de software
       são suspeitas.
       Se erros facilmente corrigíveis forem encontrados, isto
       implica que a qualidade e a confiabilidade do software estão
       aceitáveis ou os testes são inadequados para revelar erros
       graves
       Se não for encontrado erro isto implica que a
       configuração de teste não foi suficientemente elaborada e
       erros estão escondidos no software


Validação de Software – Módulo 1 Conceitos Básicos          Transparência 29
1.5 O Processo de Teste




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 30
2. Contexto


            2.1 Princípios Básicos
            2.2 Estratégia de Teste
            2.3 Verificação e Validação
            2.4 Garantia de Qualidade de Software




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 31
2.1 Princípios Básicos

   Teste é um conjunto de atividades que pode ser planejado
   antecipadamente e realizado sistematicamente.
      - o planejamento e a realização das atividades de teste
        definem a estratégia de testes de software.
      - uma estratégia de teste de software define técnicas de
        projeto de casos de teste e métodos de teste específicos
        para cada etapa do processo de engenharia de software.




Validação de Software – Módulo 1 Conceitos Básicos              Transparência 32
2.2 Estratégia de Teste de Software


      Uma Estratégia de Teste deve acomodar testes de baixo nível e
      testes de alto nível, deve oferecer orientação ao profissional,
      deve oferecer um conjunto de marcos de referência ao
      administrador e deve ser mensurável.




Validação de Software – Módulo 1 Conceitos Básicos             Transparência 33
Características das Estratégias de Teste (a)

      –    a atividade de teste inicia-se no nível de módulos e
          prossegue "para fora", na direção da integração de todo o
          sistema
      – diferentes técnicas de teste são apropriadas a diferentes
        pontos de tempo.
      – a atividade de teste é realizada pela equipe de
        desenvolvimento do software e para grandes projetos por
        um grupo de teste independente.



Validação de Software – Módulo 1 Conceitos Básicos          Transparência 34
Características das Estratégias de Teste (b)


     – as atividades de teste e de depuração são atividades
       diferentes, mas a depuração deve ser acomodada em
       qualquer estratégia de teste.
     – deve oferecer um conjunto de marcos de referência ao
       administrador e deve ser mensurável.




Validação de Software – Módulo 1 Conceitos Básicos       Transparência 35
2.3 Verificação e Validação (V&V)

      A atividade de teste de software é um elemento de um tema
      mais amplo chamado Verificação e Validação (V&V).


      A definição de V&V abrange muitas das atividades às quais
      nos referimos como Garantia da Qualidade de Software
      (SQA).




Validação de Software – Módulo 1 Conceitos Básicos     Transparência 36
Verificação


       refere-se ao conjunto de atividades que garante que o
    software implementa corretamente uma função específica.
                    “Estamos construindo certo o produto?”




Validação de Software – Módulo 1 Conceitos Básicos           Transparência 37
Validação

      refere-se ao conjunto de atividades que garante que o
  software que foi construído é “rastreável” às exigências do
  cliente.
                   “Estamos construindo o produto certo?”




Validação de Software – Módulo 1 Conceitos Básicos          Transparência 38
2.4 Garantia da Qualidade de Software

      – Métodos de Engenharia de Software: proporcionam a base
      a partir da qual a qualidade é construída.
      – Revisões Técnicas Formais: ajudam a garantir a qualidade
      do produto produzido como uma conseqüência de cada passo
      da engenharia de software.
      – Medição: ajudam a controlar cada elemento da
      configuração de software.




Validação de Software – Módulo 1 Conceitos Básicos       Transparência 39
Garantia da Qualidade de Software (cont.)

     – Padrões e Procedimentos: ajudam a garantir a uniformidade.
     – Garantia de Qualidade de Software (SQA): põe em prática
     uma filosofia de qualidade total.
     – Teste: a qualidade pode ser avaliada.




Validação de Software – Módulo 1 Conceitos Básicos      Transparência 40
Validação de Software – Módulo 1 Conceitos Básicos   Transparência 41
3. Organização para Realização de Testes

         3.1 Desenvolvedores x Testadores
         3.2 Como as pessoas vêem os testes
         3.3 O Grupo Independente de Teste
         3.4 Etapas do Teste de Software
         3.5 Critérios para Conclusão de Testes




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 42
3.1 Desenvolvedores x Testadores

     Quando o teste se inicia há um conflito de interesses:

       –Desenvolvedores: interesse em demonstrar que o
       programa é isento de erros.

       –Responsáveis pelos testes: interesse em mostrar que o
       programa tem erros.




Validação de Software – Módulo 1 Conceitos Básicos       Transparência 43
3.2 Como as Pessoas Vêem os Testes

      Do ponto de vista psicológico, as pessoas vêem os testes
      com uma tarefa destrutiva:

      • Análise, Projeto e Codificação de Software são tarefas
      construtivas

      • Teste é tarefa destrutiva pois visa descobrir problemas




Validação de Software – Módulo 1 Conceitos Básicos          Transparência 44
3.3 Grupo Independente de Teste

           Para suprir o conflito de interesses existe o Grupo
           Independente de Testes (ITG).


           ITG faz parte da equipe de projeto de desenvolvimento
           de software, no sentido de estarem envolvidos durante o
           processo de especificação e continuam planejando e
           especificando procedimentos de teste ao longo de um
           grande projeto.



Validação de Software – Módulo 1 Conceitos Básicos           Transparência 45
3.4 Etapas do Teste de Software

      Testes de Unidade: cada módulo é testado individualmente
   garantindo que ele funcione adequadamente. Utiliza as técnicas de
   teste de caixa branca.
                  branca
      Testes de Integração: os módulos são montados ou integrados
   para formarem um pacote de software. Utiliza principalmente as
   técnicas de teste de caixa preta.
                              preta
     Testes de Alto Nível (validação e sistema): Os critérios de
   validação estabelecidos durante a análise de requisitos são testados.
   Verifica também se todos os elementos combinam-se adequadamente
   e se a função/ desempenho global do sistema é conseguida. Utiliza as
   técnicas de caixa preta.
                     preta


Validação de Software – Módulo 1 Conceitos Básicos             Transparência 46
Etapas do Teste de Software




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 47
3.5 Critérios para Conclusão de Teste

   Quando realizamos testes, como saber se já testamos o
   suficiente?


   Respostas pragmáticas:
     Você jamais terá completado a atividade de teste; a carga
   simplesmente transfere-se do projetista para o cliente.
      Quando estiver sem tempo ou sem dinheiro.




Validação de Software – Módulo 1 Conceitos Básicos         Transparência 48
Um Modelo Empírico (a)

    Modelo Logarítmico do Tempo de Execução de Poisson:
    intensidade de erros real pode ser traçada em relação a curva
    prevista.




Validação de Software – Módulo 1 Conceitos Básicos         Transparência 49
Um Modelo Empírico (b)




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 50
4 Executando Testes
    4.1 Níveis de Testes
    4.2 Teste de Unidade
    4.3 Teste de Integração
    4.4 Teste de Validação
    4.5 Teste de Sistema




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 51
4.1 Níveis de Teste

     Teste de Unidade: concentra-se em cada unidade do software,
   de acordo com o que é implementado no código fonte.
     Teste de Integração: concentra-se no projeto e na construção
   da arquitetura de software.
     Teste de Validação: em como o software que foi construído é
   validado em relação aos requisitos de software.
     Teste de Sistema: o software e outros elementos do sistema
   são testados como um todo.




Validação de Software – Módulo 1 Conceitos Básicos       Transparência 52
Validação de Software – Módulo 1 Conceitos Básicos   Transparência 53
4.2 Teste de Unidade


    Os Testes de Unidade concentram-se em cada unidade do
   software, de acordo com o que é implementado no código fonte.




Validação de Software – Módulo 1 Conceitos Básicos      Transparência 54
O Que é Testado (a)

     a interface com o módulo é testada para ter a garantia de que
  as informações fluem para dentro e para fora da unidade de
  programa que se encontra sob teste

     a estrutura de dados local é examinada para ter a garantia
  de que dados armazenados temporariamente mantêm sua
  integridade durante todos os passos de execução.




Validação de Software – Módulo 1 Conceitos Básicos        Transparência 55
O Que é Testado (b)

     as condições de limite são testadas para ter a garantia de que
  o módulo opera adequadamente nos limites estabelecidos para
  demarcarem ou restringirem o processamento.


     todos os caminhos independentes através da estrutura de
  controle são exercitados para ter a garantia de que todas as
  instruções de um módulo foram executadas pelo menos uma
  vez.




Validação de Software – Módulo 1 Conceitos Básicos         Transparência 56
O Que é Testado (c)

          todos os caminhos de tratamento de erros são testados.



                                              Interface
                                              Estruturas de dados locais
                                              Condições limite
                                              Caminhos independentes
                                              Caminhos de tratamento de erros


                                                     Casos de Teste




Validação de Software – Módulo 1 Conceitos Básicos                          Transparência 57
O Ambiente de Teste de Unidade (a)


       Uma vez que o módulo não é um programa individual, um
       software driver e/ou stub deve ser desenvolvido para cada
       unidade de teste.




Validação de Software – Módulo 1 Conceitos Básicos        Transparência 58
O Ambiente de Teste de Unidade (b)

     Driver na maioria das aplicações é um programa principal que
   aceita dados de caso de teste, passa tais dados para o módulo a
   ser testado e imprime os dados relevantes.

      Stub ou programa simulado - serve para substituir módulos
   que estejam subordinados (chamados pelo) ao módulo a ser
   testado. Usa a interface do módulo subordinado, pode fazer
   manipulação de dados mínima, imprime verificação de entrada e
   retorna.



Validação de Software – Módulo 1 Conceitos Básicos       Transparência 59
O Ambiente de Teste de Unidade (c)

                                                     • Interface

                                                     • Estruturas de dados
                                                     locais
                                       Driver        • Condições limites

                                                     • Caminhos execução

                 módulo a                            • Caminhos de tratamento
                ser testado                          de erros



                                        Resultados
      Stub 1         Stub 2
                                                                   casos de teste



Validação de Software – Módulo 1 Conceitos Básicos                    Transparência 60
4.3 Teste de Integração

       Os Testes de Integração concentram-se no projeto e na
      construção da arquitetura de software, almejam descobrir
      erros associados a interfaces.
                         interfaces


       O objetivo é, a partir dos módulos testados ao nível de
      unidade, integrá-los, e testar se a estrutura de programa
      construída foi aquela determinada pelo projeto.




Validação de Software – Módulo 1 Conceitos Básicos         Transparência 61
Validação de Software – Módulo 1 Conceitos Básicos   Transparência 62
Abordagens
 Integração não incremental: (abordagem “big-bang”) o
 programa completo é testado como um todo e o resultado é o
 caos. Quando erros são encontrados, a correção é difícil porque o
 isolamento das causas é complicado pela vasta amplitude do
 programa inteiro.
 Integração incremental: o programa é construído e testado em
 pequenos segmentos, onde os erros são mais fáceis de serem
 isolados e corrigidos; as interfaces têm maior probabilidade de
 serem testadas completamente e uma abordagem sistemática ao
 teste pode ser aplicada.


Validação de Software – Módulo 1 Conceitos Básicos       Transparência 63
Integração Top-Down (a)

      Os módulos são integrados movimentando-se de cima para
   baixo, através da hierarquia de controle, iniciando-se do módulo
   de controle principal.

      Os módulos subordinados ao módulo de controle principal
   são incorporados à estrutura de uma maneira depth-first
   (primeiro pela profundidade) ou breadth-first (primeiramente
   pela largura).




Validação de Software – Módulo 1 Conceitos Básicos        Transparência 64
Integração Top-Down (b)




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 65
Passos do Processo de Integração Top-Down (a)

        1. o módulo de controle é usado como um driver de teste e
        os stubs são substituídos para todos os módulos
        diretamente subordinados ao módulo de controle principal.


        2. dependendo da abordagem de integração escolhida, os
        stubs subordinados são substituídos, um de cada vez por
        módulos reais.

        3. testes são realizados à medida que cada módulo é
        integrado.

Validação de Software – Módulo 1 Conceitos Básicos            Transparência 66
Passos do Processo de Integração Top-Down (b)


     4. durante a conclusão de cada conjunto de testes, outro stub
     é substituído pelo módulo real.


     5. teste de regressão - (realização de todos ou de alguns dos
     testes anteriores) pode ser realizado a fim de garantir que
     novos erros não tenham sido introduzidos.




Validação de Software – Módulo 1 Conceitos Básicos          Transparência 67
4.4 Teste de Validação


    Os Testes de Validação concentram-se em como os requisitos
   estabelecidos como parte da análise de requisitos de software
   são validados em relação ao software que foi construído.




Validação de Software – Módulo 1 Conceitos Básicos       Transparência 68
Validação de Software – Módulo 1 Conceitos Básicos   Transparência 69
Contexto

      Ao término da atividade de teste de integração, o software
      está completamente montado como um pacote, erros de
      interface foram descobertos e corrigidos e uma série final
      de testes de software - os testes de validação - pode iniciar-
      se.




Validação de Software – Módulo 1 Conceitos Básicos           Transparência 70
Princípios (a)
       A validação é bem sucedida quando o software funciona de
     uma maneira razoavelmente esperada pelo cliente.
       A Especificação de Requisitos de Software contém os
     critérios de validação que formam a base para uma
     abordagem ao teste de validação.
       A validação do software é realizada por meio de uma série
     de testes de caixa preta que demonstram a conformidade com
     os requisitos.




Validação de Software – Módulo 1 Conceitos Básicos       Transparência 71
Princípios (b)

    O plano e o procedimento de teste são projetados para garantir
    que:
        todos os requisitos funcionais são satisfeitos
        todos os requisitos de desempenho são conseguidos
        a documentação está correta
      outros requisitos são cumpridos: portabilidade,
    compatibilidade, remoção de erros e manutenabilidade




Validação de Software – Módulo 1 Conceitos Básicos          Transparência 72
Revisão de Configuração

     Um elemento importante do processo de validação é a revisão
     de configuração ou auditoria




     O propósito dessa revisão é garantir que todos os elementos
     da configuração de software tenham sido adequadamente
     desenvolvidos, estão catalogados e têm os detalhes
     necessários para apoiar a fase de manutenção do ciclo de vida
     do software.


Validação de Software – Módulo 1 Conceitos Básicos        Transparência 73
Validação de Software – Módulo 1 Conceitos Básicos   Transparência 74
Testes Alfa e Beta x Teste de Aceitação

    É virtualmente impossível que se preveja como o cliente
    realmente usará/reagirá a um programa (as instruções de uso
    podem ser mal-interpretadas, combinações estranhas de dados
    podem ser irregularmente usadas, saídas que pareciam claras ao
    analista podem ser ininteligíveis para um usuários, etc).
    Testes devem ser feitos para se saber isto. Existem duas famílias
    de testes com esta finalidade:
      – Testes de Aceitação

      – Testes Alfa e Testes Beta


Validação de Software – Módulo 1 Conceitos Básicos         Transparência 75
Teste de Aceitação

     Usado quando o software é customizado para um cliente


          objetiva capacitar/permitir ao usuário final a validar
       todos os requisitos.

          pode variar de um test drive informal a uma série de
       testes planejados.




Validação de Software – Módulo 1 Conceitos Básicos           Transparência 76
Testes Alfa e Beta (a)

     Usado quando o software é desenvolvido como um produto
     para muitos clientes, geralmente tem duas fases:


     Teste Alfa - é levado a efeito por um cliente nas instalações do
     desenvolvedor.

       O software é usado num ambiente controlado com o desenvolvedor
       "olhando sobre os ombros" do usuário e registrando erros e problemas de
       uso.



Validação de Software – Módulo 1 Conceitos Básicos                  Transparência 77
Testes Alfa e Beta (b)


      Teste Beta - é realizado nas instalações do cliente pelo
      usuário final do software. O desenvolvedor não está
      presente.

        O cliente registra os problemas (reais ou imaginários) que são
        encontrados e relata-os ao desenvolvedor a intervalos regulares.




Validação de Software – Módulo 1 Conceitos Básicos                    Transparência 78
4.5 Teste de Sistema

       O software é apenas um elemento de um sistema
            baseado em computador mais amplo.

    O teste de sistema envolve uma série de diferentes testes,
    cujo propósito primordial é por completamente à prova o
    sistema baseado em computador.




Validação de Software – Módulo 1 Conceitos Básicos     Transparência 79
Validação de Software – Módulo 1 Conceitos Básicos   Transparência 80
Um Problema Clássico no Teste de Sistema


      "apontar o dedo" - quando ocorre um erro, o desenvolvedor
      de um elemento do sistema culpa outro pelo problema.




Validação de Software – Módulo 1 Conceitos Básicos     Transparência 81
Princípios
   O engenheiro de sistema deve antecipar os problemas
   potenciais da interface:
   1. projetar caminhos de tratamento de erros que testem todas as
   informações que chegam de outros elementos do sistema.
   2. realizar uma série de testes que simulem dados ruins ou
   outros erros em potencial na interface do software.
   3. registrar os resultados de teste para usar como "prova" se
   alguém lhe apontar o dedo.
   4. participar do planejamento e projeto dos testes do sistema
   para garantir que o software seja adequadamente testado.


Validação de Software – Módulo 1 Conceitos Básicos         Transparência 82
Teste de Recuperação

Muitos sistemas baseados em computador precisam recuperar-se de
falhas e retomar o processamento dentro de um tempo previamente
especificado. Em certos casos, o sistema deve tolerar falhas, isto é,
o processamento de falhas não deve fazer com que uma função
global de sistema cesse. Em outros casos, uma falha do sistema
deve ser corrigida dentro de um período previamente especificado;
caso contrário, graves prejuízos econômicos ocorrerão.

O teste de recuperação é um teste de sistema que força o software a
falhar de diversas maneiras e verifica se a recuperação é
adequadamente executada.


Validação de Software – Módulo 1 Conceitos Básicos         Transparência 83
Teste de Segurança (a)

  Qualquer sistema baseado em computador que gerencie
  informações delicadas ou provoque ações que possam
  impropriamente prejudicar (ou beneficiar) pessoas constitui um
  alvo para o acesso impróprio ou ilegal.


  O teste de segurança tenta verificar se todos os mecanismos de
  proteção embutidos num sistema o protegerão, de fato, de
  acessos indevidos.



Validação de Software – Módulo 1 Conceitos Básicos       Transparência 84
Teste de Segurança (b)

   Durante o teste de segurança, o analista desempenha o papel de
   pessoa que deseja penetrar no sistema. Qualquer coisa vale!

       adquirir senhas mediante contatos externos
     atacar o sistema com software customizado projetado para
   derrubar quaisquer defesas que tenham sido construídas




Validação de Software – Módulo 1 Conceitos Básicos       Transparência 85
Teste de Segurança (c)

     desarmar o sistema, negando serviço a outros
    provocar erros intencionalmente,                 esperando   acessá-lo
  durante a recuperação
    "folhear" através de dados inseguros esperando descobrir a
  chave para a entrada no sistema.


   O papel do projetista do sistema é fazer com que o acesso custe
        mais do que o valor da informação que será obtida.



Validação de Software – Módulo 1 Conceitos Básicos                Transparência 86
5 Depurando Software

        5.5.1 O Quê é depuração
        5.5.2 Abordagens à depuração




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 87
5.5.1 O Quê é Depuração


    O objetivo primordial da depuração ou debugging é descobrir
    e corrigir a causa de um erro de software.


    A depuração ocorre em conseqüência de testes bem
    sucedidos. Embora a depuração possa e deva ser ser um
    processo disciplinado, ela ainda tem muito de arte.




Validação de Software – Módulo 1 Conceitos Básicos      Transparência 88
O Processo de Depuração




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 89
Severidade de Erros

      Durante a depuração, encontram-se erros que variam
      de brandamente perturbadores a catastróficos.


          À medida que as conseqüências de uma falha
       aumentam, a pressão para descobrir a causa também
                           aumenta.




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 90
Por que a Depuração é Difícil? (a)

  1) O sintoma e a causa podem ser geograficamente remotos.
     Estruturas altamente acopladas agravam essa situação.


  2) O sintoma pode desaparecer (temporariamente) quando
     outro erro é corrigido.


  3) O sintoma pode, de fato, ser causado por não erros (por
     exemplo, imprecisões de arredondamento).



Validação de Software – Módulo 1 Conceitos Básicos        Transparência 91
Por que a Depuração é Difícil? (b)

    4) O sintoma pode ser causado por um erro humano que não é
       facilmente rastreado.


    5) O sintoma pode ser resultado de problemas de
       temporização, e não problemas de processamento.

    6) O sintoma pode ser devido a causas que estão distribuídas
       por uma série de tarefas que são executadas em diferentes
       processadores.


Validação de Software – Módulo 1 Conceitos Básicos        Transparência 92
5.5.2 Abordagens à Depuração
    1 - Força bruta
    2 - Backtracking
    3 - Eliminação da Causa




Validação de Software – Módulo 1 Conceitos Básicos   Transparência 93
Força Bruta (a)
   A categoria de depuração por força bruta provavelmente é o
   método mais comum e menos eficiente de isolar a causa de um
   erro de software.


   Usa-se uma filosofia do tipo "deixe que o computador
   descubra o erro". Por exemplo, são feitas listagens de memória
   (memory dumps), são inseridas instruções WRITE, etc.


   Aplica-se o método de força bruta quando tudo o mais falha.



Validação de Software – Módulo 1 Conceitos Básicos       Transparência 94
Força Bruta (b)


     Espera-se encontrar, em algum lugar do emaranhado de
     informações, uma pista que possa levar à causa de um erro.
     Não obstante, a massa de informações produzida possa levar
     ao sucesso, mais freqüentemente ela conduz a tempo e esforço
     desperdiçados.
     Deve-se gastar o raciocínio primeiro.




Validação de Software – Módulo 1 Conceitos Básicos        Transparência 95
Backtracking

   Iniciando-se no local em que o sintoma foi descoberto, o
   código fonte é rastreado para trás (manualmente) até que o
   local da causa seja encontrado.


   É uma abordagem que pode ser usada com sucesso em
   pequenos programas.

   Infelizmente, à medida que o número de linhas de código
   aumenta, o número de potenciais caminhos de backtracking
   pode tornar-se incontrolavelmente alto.


Validação de Software – Módulo 1 Conceitos Básicos     Transparência 96
Eliminação da Causa
  Os dados relacionados à ocorrência de erros são organizados
  para isolar potenciais causas.


  Uma "hipótese de causa" é imaginada e os dados são usados
  para provar ou refutar a hipótese. Alternativamente, uma lista de
  todas as causas possíveis é desenvolvida e testes são realizados
  para eliminar cada uma delas.


  Se os testes iniciais indicarem que uma hipótese de causa
  apresenta possibilidades, os dados são refinados, numa tentativa
  de isolar o bug.


Validação de Software – Módulo 1 Conceitos Básicos        Transparência 97
5.5.3 Dicas Sobre Depuração (a)

        As abordagens de depuração podem ser complementadas
        com ferramentas de depuração:
           compiladores de depuração,
           auxílio rastreadores de depuração dinâmicos,
          geradores de casos de teste automáticos, geradores de
        dumps de memória e
           geradores de mapas de referência cruzada.




Validação de Software – Módulo 1 Conceitos Básicos         Transparência 98
Dicas Sobre Depuração (b)

    Um poderoso aliado à depuração são "outras pessoas".
    O conceito de “programação não egoística” deve ser ampliado
    para "depuração não egoística".




Validação de Software – Módulo 1 Conceitos Básicos         Transparência 99
Dicas Sobre Depuração (c)

  Assim que um erro é encontrado, ele deve ser corrigido, porém a
  correção de um erro pode introduzir outros erros. Assim, deve-
  se fazer 3 perguntas simples, sempre que se realizar uma
  "correção" que removerá a causa de um erro:
  1- A causa do bug é reproduzida em outra parte do programa?
  2- Qual "bug seguinte" poderia ser introduzido pelo reparo que
  se está prestes a fazer?
  3- O que poderia ter sido feito para eliminar este bug desde o
  princípio?



Validação de Software – Módulo 1 Conceitos Básicos         Transparência 100

Mais conteúdo relacionado

Mais procurados

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
 
Aula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptxAula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptx
AlexandreLisboadaSil
 
Introdução a testes unitários com jUnit
Introdução a testes unitários com jUnitIntrodução a testes unitários com jUnit
Introdução a testes unitários com jUnit
Leonardo Soares
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
Leinylson Fontinele
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1
Elaine Cecília Gatto
 
Palestra - Heurísticas e Usabilidade
Palestra - Heurísticas e UsabilidadePalestra - Heurísticas e Usabilidade
Palestra - Heurísticas e Usabilidade
Luiz Agner
 
Técnicas de Testes Funcionais Caixa-Preta
Técnicas de Testes Funcionais Caixa-PretaTécnicas de Testes Funcionais Caixa-Preta
Técnicas de Testes Funcionais Caixa-Preta
Lucas Amaral
 
Teste de Software - Introdução
Teste de Software - IntroduçãoTeste de Software - Introdução
Teste de Software - Introdução
Joeldson Costa Damasceno
 
오픈 소스 도구를 활용한 성능 테스트 방법 및 사례
오픈 소스 도구를 활용한 성능 테스트 방법 및 사례오픈 소스 도구를 활용한 성능 테스트 방법 및 사례
오픈 소스 도구를 활용한 성능 테스트 방법 및 사례
MinWoo Byeon
 
Técnicas de Teste
Técnicas de TesteTécnicas de Teste
Técnicas de Teste
Camilo Ribeiro
 
Validação e Testes de Software - MOD2
Validação e Testes de Software - MOD2Validação e Testes de Software - MOD2
Validação e Testes de Software - MOD2
Fernando Palma
 
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
 
ISO 15504
ISO 15504ISO 15504
ISO 15504
Marcelo Ramos
 
Teste de software
Teste de softwareTeste de software
Teste de software
COTIC-PROEG (UFPA)
 
Como descrever cenários de teste utilizando Gherkin de forma correta
Como descrever cenários de teste utilizando Gherkin de forma corretaComo descrever cenários de teste utilizando Gherkin de forma correta
Como descrever cenários de teste utilizando Gherkin de forma correta
Testing Dojo Uai
 
TDD - Test Driven Development
TDD - Test Driven DevelopmentTDD - Test Driven Development
TDD - Test Driven Development
Elias Nogueira
 
Automação de teste de software
Automação de teste de softwareAutomação de teste de software
Automação de teste de software
Qualister
 
De a máxima cobertura nos seus testes de API
De a máxima cobertura nos seus testes de APIDe a máxima cobertura nos seus testes de API
De a máxima cobertura nos seus testes de API
Elias Nogueira
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
Cloves da Rocha
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
Nécio de Lima Veras
 

Mais procurados (20)

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
 
Aula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptxAula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptx
 
Introdução a testes unitários com jUnit
Introdução a testes unitários com jUnitIntrodução a testes unitários com jUnit
Introdução a testes unitários com jUnit
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1
 
Palestra - Heurísticas e Usabilidade
Palestra - Heurísticas e UsabilidadePalestra - Heurísticas e Usabilidade
Palestra - Heurísticas e Usabilidade
 
Técnicas de Testes Funcionais Caixa-Preta
Técnicas de Testes Funcionais Caixa-PretaTécnicas de Testes Funcionais Caixa-Preta
Técnicas de Testes Funcionais Caixa-Preta
 
Teste de Software - Introdução
Teste de Software - IntroduçãoTeste de Software - Introdução
Teste de Software - Introdução
 
오픈 소스 도구를 활용한 성능 테스트 방법 및 사례
오픈 소스 도구를 활용한 성능 테스트 방법 및 사례오픈 소스 도구를 활용한 성능 테스트 방법 및 사례
오픈 소스 도구를 활용한 성능 테스트 방법 및 사례
 
Técnicas de Teste
Técnicas de TesteTécnicas de Teste
Técnicas de Teste
 
Validação e Testes de Software - MOD2
Validação e Testes de Software - MOD2Validação e Testes de Software - MOD2
Validação e Testes de Software - MOD2
 
Qualidade de Software: Modelos e normas
Qualidade de Software: Modelos e normasQualidade de Software: Modelos e normas
Qualidade de Software: Modelos e normas
 
ISO 15504
ISO 15504ISO 15504
ISO 15504
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
Como descrever cenários de teste utilizando Gherkin de forma correta
Como descrever cenários de teste utilizando Gherkin de forma corretaComo descrever cenários de teste utilizando Gherkin de forma correta
Como descrever cenários de teste utilizando Gherkin de forma correta
 
TDD - Test Driven Development
TDD - Test Driven DevelopmentTDD - Test Driven Development
TDD - Test Driven Development
 
Automação de teste de software
Automação de teste de softwareAutomação de teste de software
Automação de teste de software
 
De a máxima cobertura nos seus testes de API
De a máxima cobertura nos seus testes de APIDe a máxima cobertura nos seus testes de API
De a máxima cobertura nos seus testes de API
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
 

Destaque

Ctai Teste De Software Aula 1
Ctai Teste De Software Aula 1Ctai Teste De Software Aula 1
Ctai Teste De Software Aula 1
Victor Hugo Germano
 
Ctai Teste De Software Aula 2
Ctai Teste De Software Aula 2Ctai Teste De Software Aula 2
Ctai Teste De Software Aula 2
Victor Hugo Germano
 
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
 
Analise de Requisitos Software
Analise de Requisitos SoftwareAnalise de Requisitos Software
Analise de Requisitos Software
Rildo (@rildosan) Santos
 
Kelli Janae Lindsay : LRA Uganda
Kelli Janae Lindsay : LRA Uganda Kelli Janae Lindsay : LRA Uganda
Kelli Janae Lindsay : LRA Uganda
Kelli Kling
 
ingenieria del software
ingenieria del softwareingenieria del software
ingenieria del software
Evelio Hipuchima
 
Final copy lra conflict uganda
Final copy lra conflict ugandaFinal copy lra conflict uganda
Final copy lra conflict uganda
Kelli Kling
 
LRA Presentation (1)
LRA Presentation (1)LRA Presentation (1)
LRA Presentation (1)
John Michael Scott, Ph.D.
 
LRA Presentation 1
LRA Presentation 1LRA Presentation 1
LRA Presentation 1
ildikoscurr
 
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0
Sebastian Schaffert
 
Gj Sue Tr Policy
Gj Sue Tr PolicyGj Sue Tr Policy
Gj Sue Tr Policy
CallieO
 
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UMLDesenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Rildo (@rildosan) Santos
 
C-LRA Program Evaluation and Needs Assessment
C-LRA Program Evaluation and Needs AssessmentC-LRA Program Evaluation and Needs Assessment
C-LRA Program Evaluation and Needs Assessment
Robert Grossman-Vermaas
 
LRA Investor Presentation 13 05-17
LRA Investor Presentation 13 05-17 LRA Investor Presentation 13 05-17
LRA Investor Presentation 13 05-17
Lara_Exploration
 
Conflict in North Uganda
Conflict in North UgandaConflict in North Uganda
Conflict in North Uganda
Arundathie Abeysinghe
 
Semantic Relations
Semantic RelationsSemantic Relations
Semantic Relations
Jennifer Lee
 
Open Source Software im geschäftskritischen Einsatz
Open Source Software im geschäftskritischen EinsatzOpen Source Software im geschäftskritischen Einsatz
Open Source Software im geschäftskritischen Einsatz
Matthias Stürmer
 
Projektmanagement 2.0: Social Software für die Projektkommunikation
Projektmanagement 2.0: Social Software für die ProjektkommunikationProjektmanagement 2.0: Social Software für die Projektkommunikation
Projektmanagement 2.0: Social Software für die Projektkommunikation
Kommunikation-zweinull
 
13 03-01 lra investor presentation
13 03-01 lra investor presentation13 03-01 lra investor presentation
13 03-01 lra investor presentation
Lara_Exploration
 
20100822 opensmt bruttomesso
20100822 opensmt bruttomesso20100822 opensmt bruttomesso
20100822 opensmt bruttomesso
Computer Science Club
 

Destaque (20)

Ctai Teste De Software Aula 1
Ctai Teste De Software Aula 1Ctai Teste De Software Aula 1
Ctai Teste De Software Aula 1
 
Ctai Teste De Software Aula 2
Ctai Teste De Software Aula 2Ctai Teste De Software Aula 2
Ctai Teste De Software Aula 2
 
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
 
Analise de Requisitos Software
Analise de Requisitos SoftwareAnalise de Requisitos Software
Analise de Requisitos Software
 
Kelli Janae Lindsay : LRA Uganda
Kelli Janae Lindsay : LRA Uganda Kelli Janae Lindsay : LRA Uganda
Kelli Janae Lindsay : LRA Uganda
 
ingenieria del software
ingenieria del softwareingenieria del software
ingenieria del software
 
Final copy lra conflict uganda
Final copy lra conflict ugandaFinal copy lra conflict uganda
Final copy lra conflict uganda
 
LRA Presentation (1)
LRA Presentation (1)LRA Presentation (1)
LRA Presentation (1)
 
LRA Presentation 1
LRA Presentation 1LRA Presentation 1
LRA Presentation 1
 
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0
Social Software und Web 2.0: Semantic Wikis, Social Tagging und eLearning 2.0
 
Gj Sue Tr Policy
Gj Sue Tr PolicyGj Sue Tr Policy
Gj Sue Tr Policy
 
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UMLDesenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
 
C-LRA Program Evaluation and Needs Assessment
C-LRA Program Evaluation and Needs AssessmentC-LRA Program Evaluation and Needs Assessment
C-LRA Program Evaluation and Needs Assessment
 
LRA Investor Presentation 13 05-17
LRA Investor Presentation 13 05-17 LRA Investor Presentation 13 05-17
LRA Investor Presentation 13 05-17
 
Conflict in North Uganda
Conflict in North UgandaConflict in North Uganda
Conflict in North Uganda
 
Semantic Relations
Semantic RelationsSemantic Relations
Semantic Relations
 
Open Source Software im geschäftskritischen Einsatz
Open Source Software im geschäftskritischen EinsatzOpen Source Software im geschäftskritischen Einsatz
Open Source Software im geschäftskritischen Einsatz
 
Projektmanagement 2.0: Social Software für die Projektkommunikation
Projektmanagement 2.0: Social Software für die ProjektkommunikationProjektmanagement 2.0: Social Software für die Projektkommunikation
Projektmanagement 2.0: Social Software für die Projektkommunikation
 
13 03-01 lra investor presentation
13 03-01 lra investor presentation13 03-01 lra investor presentation
13 03-01 lra investor presentation
 
20100822 opensmt bruttomesso
20100822 opensmt bruttomesso20100822 opensmt bruttomesso
20100822 opensmt bruttomesso
 

Semelhante a Validação e Testes de Software - MOD1

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
 
Aula - Teste de Software
Aula - Teste de SoftwareAula - Teste de Software
Aula - Teste de Software
Mauricio Cesar Santos da Purificação
 
X-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de SoftwareX-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de Software
AlexandreBartie
 
Introdução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade IIntrodução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade I
João Lourenço
 
Aula18_V&VTesteSoftware.pdf
Aula18_V&VTesteSoftware.pdfAula18_V&VTesteSoftware.pdf
Aula18_V&VTesteSoftware.pdf
MichaelArrais1
 
Teste de software
Teste de software Teste de software
Teste de software
Allan Almeida de Araújo
 
Teste de software
Teste de softwareTeste de software
Teste de software
Rodrigo Cardoso Alves Fonte
 
3 engenharia de software
3   engenharia de software3   engenharia de software
3 engenharia de software
Felipe Bugov
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
testedesoftwarepe
 
TesteDeSoftware_WorkshopSINFO2014.pdf
TesteDeSoftware_WorkshopSINFO2014.pdfTesteDeSoftware_WorkshopSINFO2014.pdf
TesteDeSoftware_WorkshopSINFO2014.pdf
Bruno Zolotareff dos Santos
 
Dba Testes Gerentes B2
Dba Testes Gerentes B2Dba Testes Gerentes B2
Dba Testes Gerentes B2
Leonardo Molinari
 
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
 
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
 
Engenharia de software
Engenharia de software Engenharia de software
Engenharia de software
MarcosSilva941136
 
Conceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidadeConceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidade
rzauza
 
1 Qss
1 Qss1 Qss
1 Qss
lcbj
 
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
 
Questionario CTFL - Foundation Level
Questionario CTFL - Foundation LevelQuestionario CTFL - Foundation Level
Questionario CTFL - Foundation Level
Lucas Bonanno Casanova
 
Implantação de um Processo de Teste de Software
Implantação de um Processo de Teste de SoftwareImplantação de um Processo de Teste de Software
Implantação de um Processo de Teste de Software
Randerson Oliveira Melville Rebouças
 
Implantação de um Processo de Teste de Software - Randerson Melville
Implantação de um Processo de Teste de Software - Randerson Melville Implantação de um Processo de Teste de Software - Randerson Melville
Implantação de um Processo de Teste de Software - Randerson Melville
minastestingconference
 

Semelhante a Validação e Testes de Software - MOD1 (20)

Introdução a testes de sofwtare
Introdução a testes de sofwtareIntrodução a testes de sofwtare
Introdução a testes de sofwtare
 
Aula - Teste de Software
Aula - Teste de SoftwareAula - Teste de Software
Aula - Teste de Software
 
X-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de SoftwareX-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de Software
 
Introdução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade IIntrodução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade I
 
Aula18_V&VTesteSoftware.pdf
Aula18_V&VTesteSoftware.pdfAula18_V&VTesteSoftware.pdf
Aula18_V&VTesteSoftware.pdf
 
Teste de software
Teste de software Teste de software
Teste de software
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
3 engenharia de software
3   engenharia de software3   engenharia de software
3 engenharia de software
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
 
TesteDeSoftware_WorkshopSINFO2014.pdf
TesteDeSoftware_WorkshopSINFO2014.pdfTesteDeSoftware_WorkshopSINFO2014.pdf
TesteDeSoftware_WorkshopSINFO2014.pdf
 
Dba Testes Gerentes B2
Dba Testes Gerentes B2Dba Testes Gerentes B2
Dba Testes Gerentes B2
 
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
 
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
 
Engenharia de software
Engenharia de software Engenharia de software
Engenharia de software
 
Conceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidadeConceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidade
 
1 Qss
1 Qss1 Qss
1 Qss
 
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
 
Questionario CTFL - Foundation Level
Questionario CTFL - Foundation LevelQuestionario CTFL - Foundation Level
Questionario CTFL - Foundation Level
 
Implantação de um Processo de Teste de Software
Implantação de um Processo de Teste de SoftwareImplantação de um Processo de Teste de Software
Implantação de um Processo de Teste de Software
 
Implantação de um Processo de Teste de Software - Randerson Melville
Implantação de um Processo de Teste de Software - Randerson Melville Implantação de um Processo de Teste de Software - Randerson Melville
Implantação de um Processo de Teste de Software - Randerson Melville
 

Mais de Fernando Palma

CRM Gerenciamento Do Relacionamento Com Clientes | Prof. Francisco Alves | C...
CRM Gerenciamento Do Relacionamento Com Clientes | Prof. Francisco Alves |  C...CRM Gerenciamento Do Relacionamento Com Clientes | Prof. Francisco Alves |  C...
CRM Gerenciamento Do Relacionamento Com Clientes | Prof. Francisco Alves | C...
Fernando Palma
 
Formação em ciência de dados
Formação em ciência de dadosFormação em ciência de dados
Formação em ciência de dados
Fernando Palma
 
Apostila de Introdução ao Arduino
Apostila de Introdução ao ArduinoApostila de Introdução ao Arduino
Apostila de Introdução ao Arduino
Fernando Palma
 
Apostila Arduino Basico
Apostila Arduino BasicoApostila Arduino Basico
Apostila Arduino Basico
Fernando Palma
 
Cartilha Segurança na Internet - CERT.br
Cartilha Segurança na Internet - CERT.brCartilha Segurança na Internet - CERT.br
Cartilha Segurança na Internet - CERT.br
Fernando Palma
 
Ebook Apache Server: Guia Introdutório
Ebook Apache Server: Guia IntrodutórioEbook Apache Server: Guia Introdutório
Ebook Apache Server: Guia Introdutório
Fernando Palma
 
Apostila Zend Framework
Apostila Zend FrameworkApostila Zend Framework
Apostila Zend Framework
Fernando Palma
 
Hacker Ético
Hacker ÉticoHacker Ético
Hacker Ético
Fernando Palma
 
Ebook Governança de TI na Prática
Ebook Governança de TI na PráticaEbook Governança de TI na Prática
Ebook Governança de TI na Prática
Fernando Palma
 
Simulado ITIL Foundation - Questões Comentadas
Simulado ITIL Foundation - Questões ComentadasSimulado ITIL Foundation - Questões Comentadas
Simulado ITIL Foundation - Questões Comentadas
Fernando Palma
 
Introdução à Aprendizagem de Máquina
Introdução à Aprendizagem de MáquinaIntrodução à Aprendizagem de Máquina
Introdução à Aprendizagem de Máquina
Fernando Palma
 
PDTI - Plano Diretor de Tecnologia da Informação (modelo)
PDTI - Plano Diretor de Tecnologia da Informação (modelo)PDTI - Plano Diretor de Tecnologia da Informação (modelo)
PDTI - Plano Diretor de Tecnologia da Informação (modelo)
Fernando Palma
 
Guia Salarial 2017 Robert Half Brasil
Guia Salarial 2017 Robert Half BrasilGuia Salarial 2017 Robert Half Brasil
Guia Salarial 2017 Robert Half Brasil
Fernando Palma
 
Tutorial memcached
Tutorial memcachedTutorial memcached
Tutorial memcached
Fernando Palma
 
Gerenciamento na nuvem e System Center
Gerenciamento na nuvem e System CenterGerenciamento na nuvem e System Center
Gerenciamento na nuvem e System Center
Fernando Palma
 
SAN: Storage Area Network
SAN: Storage Area NetworkSAN: Storage Area Network
SAN: Storage Area Network
Fernando Palma
 
Linguagem ABAP
Linguagem ABAPLinguagem ABAP
Linguagem ABAP
Fernando Palma
 
Ebook ITIL Na Prática
Ebook ITIL Na PráticaEbook ITIL Na Prática
Ebook ITIL Na Prática
Fernando Palma
 
Exemplo de Plano Estratégico de TI - MEC
Exemplo de Plano Estratégico de TI - MECExemplo de Plano Estratégico de TI - MEC
Exemplo de Plano Estratégico de TI - MEC
Fernando Palma
 
Apostila Tutorial CakePHP
Apostila Tutorial CakePHPApostila Tutorial CakePHP
Apostila Tutorial CakePHP
Fernando Palma
 

Mais de Fernando Palma (20)

CRM Gerenciamento Do Relacionamento Com Clientes | Prof. Francisco Alves | C...
CRM Gerenciamento Do Relacionamento Com Clientes | Prof. Francisco Alves |  C...CRM Gerenciamento Do Relacionamento Com Clientes | Prof. Francisco Alves |  C...
CRM Gerenciamento Do Relacionamento Com Clientes | Prof. Francisco Alves | C...
 
Formação em ciência de dados
Formação em ciência de dadosFormação em ciência de dados
Formação em ciência de dados
 
Apostila de Introdução ao Arduino
Apostila de Introdução ao ArduinoApostila de Introdução ao Arduino
Apostila de Introdução ao Arduino
 
Apostila Arduino Basico
Apostila Arduino BasicoApostila Arduino Basico
Apostila Arduino Basico
 
Cartilha Segurança na Internet - CERT.br
Cartilha Segurança na Internet - CERT.brCartilha Segurança na Internet - CERT.br
Cartilha Segurança na Internet - CERT.br
 
Ebook Apache Server: Guia Introdutório
Ebook Apache Server: Guia IntrodutórioEbook Apache Server: Guia Introdutório
Ebook Apache Server: Guia Introdutório
 
Apostila Zend Framework
Apostila Zend FrameworkApostila Zend Framework
Apostila Zend Framework
 
Hacker Ético
Hacker ÉticoHacker Ético
Hacker Ético
 
Ebook Governança de TI na Prática
Ebook Governança de TI na PráticaEbook Governança de TI na Prática
Ebook Governança de TI na Prática
 
Simulado ITIL Foundation - Questões Comentadas
Simulado ITIL Foundation - Questões ComentadasSimulado ITIL Foundation - Questões Comentadas
Simulado ITIL Foundation - Questões Comentadas
 
Introdução à Aprendizagem de Máquina
Introdução à Aprendizagem de MáquinaIntrodução à Aprendizagem de Máquina
Introdução à Aprendizagem de Máquina
 
PDTI - Plano Diretor de Tecnologia da Informação (modelo)
PDTI - Plano Diretor de Tecnologia da Informação (modelo)PDTI - Plano Diretor de Tecnologia da Informação (modelo)
PDTI - Plano Diretor de Tecnologia da Informação (modelo)
 
Guia Salarial 2017 Robert Half Brasil
Guia Salarial 2017 Robert Half BrasilGuia Salarial 2017 Robert Half Brasil
Guia Salarial 2017 Robert Half Brasil
 
Tutorial memcached
Tutorial memcachedTutorial memcached
Tutorial memcached
 
Gerenciamento na nuvem e System Center
Gerenciamento na nuvem e System CenterGerenciamento na nuvem e System Center
Gerenciamento na nuvem e System Center
 
SAN: Storage Area Network
SAN: Storage Area NetworkSAN: Storage Area Network
SAN: Storage Area Network
 
Linguagem ABAP
Linguagem ABAPLinguagem ABAP
Linguagem ABAP
 
Ebook ITIL Na Prática
Ebook ITIL Na PráticaEbook ITIL Na Prática
Ebook ITIL Na Prática
 
Exemplo de Plano Estratégico de TI - MEC
Exemplo de Plano Estratégico de TI - MECExemplo de Plano Estratégico de TI - MEC
Exemplo de Plano Estratégico de TI - MEC
 
Apostila Tutorial CakePHP
Apostila Tutorial CakePHPApostila Tutorial CakePHP
Apostila Tutorial CakePHP
 

Validação e Testes de Software - MOD1

  • 1. Validação de Software Professor Manoel Mendonça Validação de Software – Módulo 1 Conceitos Básicos Transparência 1
  • 2. Sobre a Disciplina Validação de Software – Módulo 1 Conceitos Básicos Transparência 2
  • 3. Técnicas para Avaliação da Qualidade de Produtos Testes Revisões Provas Formais Validação de Software – Módulo 1 Conceitos Básicos Transparência 3
  • 4. Instrutor • Manoel Mendonça – Sala IM 215 – Tel. 3283-6343 – Horário para alunos – quarta à tarde – manoel.mendonca@ufba.br Validação de Software – Módulo 1 Conceitos Básicos Transparência 4
  • 5. Site da Disciplina • ... Validação de Software – Módulo 1 Conceitos Básicos Transparência 5
  • 6. Bibliografia A Practitioner's Guide to Software Test Design by Lee Copeland ISBN:158053791x Artech House © 2004 http://www.opensourcetesting.org Validação de Software – Módulo 1 Conceitos Básicos Transparência 6
  • 7. Avaliações • Trabalhos, dois trabalhos • Provas, uma ou duas Validação de Software – Módulo 1 Conceitos Básicos Transparência 7
  • 8. Plataforma de Trabalho • Java e Eclipse • JUnit • Outras ferramentas Validação de Software – Módulo 1 Conceitos Básicos Transparência 8
  • 9. 0. Conceitos Básicos Validação de Software – Módulo 1 Conceitos Básicos Transparência 9
  • 10. 0.1 Defeitos e Falhas • Defeito – um problema nos requisitos, no projeto, no código, na documentação ou nos casos de teste • Falha – um problema no funcionamento do sistema Falha: conseqüência de um defeito Validação de Software – Módulo 1 Conceitos Básicos Transparência 10
  • 11. Defeitos e Falhas: Uma Visão Mais Completa Engano (mistake) => “erro” cometido “cabeça” do eng. de software Defeito (fault) => “erro” inserido no software Erro (error) => “execução” do “erro” conduzindo a um estado incorreto do software Falha (failure) => manifestação externa do “erro” Validação de Software – Módulo 1 Conceitos Básicos Transparência 11
  • 12. Principais Artefatos de Software Uma Visão Simplificada Especificação Projeto Código de requisitos Defeitos ocorrem em todos eles !!! Validação de Software – Módulo 1 Conceitos Básicos Transparência 12
  • 13. Defeitos Introduzidos ao Longo do Processo de Desenvolvimento • A maior parte é de origem humana. • São gerados na comunicação e na transformação de informações. • Permanecem presentes nos diversos produtos de software produzidos e liberados. • A maioria encontra-se em partes do produto de software raramente utilizadas e/ou executadas. Validação de Software – Módulo 1 Conceitos Básicos Transparência 13
  • 14. 0.2 Alguns Tipos de Defeitos Introduzidos Tipo de Descrição Geral Defeito Omissão Informação necessária do sistema foi omitida do artefato de software. Fato Incorreto Alguma informação no artefato de software contradiz informação do documento de outra informação no artefato de software. Inconsistência Informação contida em uma parte do artefato de software está inconsistente com outra informação no artefato de software. Ambigüidade Informação contida no artefato de software é ambígua, isto é, várias interpretações podem ser derivadas da definição levando o desenvolvedor à implementação correta. Informação Informação que é fornecida e não é necessária ou nunca Estranha utilizada Validação de Software – Módulo 1 Conceitos Básicos Transparência 14
  • 15. Tipos de Defeitos Introduzidos Copyright Guilherme Travassos COPPE/UFRJ – 2003 - http://www.cos.ufrj.br/~ght De onde os defeitos vêm? Que defeitos podemos encontrar? Outro Domínio Conhecimento do domínio Requisitos Fato incorreto Gerais Informação estranha Artefatos de Omissão Software Inconsistência Ambigüidade Validação de Software – Módulo 1 Conceitos Básicos Transparência 15
  • 16. Defeitos Introduzidos ao Longo do Processo de Desenvolvimento • Principal causa: • tradução incorreta de informações. • Quanto antes a presença do defeito for revelada, menor o custo de correção do defeito e maior a probabilidade de corrigi-lo corretamente. • Solução: • Introduzir atividades de V V & T ao longo de todo o ciclo de desenvolvimento. Validação de Software – Módulo 1 Conceitos Básicos Transparência 16
  • 17. 0.3 Verificação e Validação (V&V) As atividades de avaliação de produtos são parte do tema chamado Verificação e Validação (V&V). A definição de V&V abrange muitas das atividades às quais nos referimos como Garantia da Qualidade de Software (SQA). Validação de Software – Módulo 1 Conceitos Básicos Transparência 17
  • 18. Verificação refere-se ao conjunto de atividades que garante que o software implementa corretamente uma função específica. “Estamos construindo certo o produto?” Validação de Software – Módulo 1 Conceitos Básicos Transparência 18
  • 19. Validação refere-se ao conjunto de atividades que garante que o software que foi construído é “rastreável” às exigências do cliente. “Estamos construindo o produto certo?” Validação de Software – Módulo 1 Conceitos Básicos Transparência 19
  • 20. 0.4 Garantia da Qualidade de Software – Métodos de Engenharia de Software: proporcionam a base a partir da qual a qualidade é construída. – Revisões Técnicas Formais: ajudam a garantir a qualidade do produto produzido como uma conseqüência de cada passo da engenharia de software. – Medição: ajudam a controlar cada elemento da configuração de software. Validação de Software – Módulo 1 Conceitos Básicos Transparência 20
  • 21. Garantia da Qualidade de Software (cont.) – Padrões e Procedimentos: ajudam a garantir a uniformidade. – Garantia de Qualidade de Software (SQA): põe em prática uma filosofia de qualidade total. – Teste: a qualidade pode ser avaliada. Validação de Software – Módulo 1 Conceitos Básicos Transparência 21
  • 22. Validação de Software – Módulo 1 Conceitos Básicos Transparência 22
  • 23. Teste de Software Validação de Software – Módulo 1 Conceitos Básicos Transparência 23
  • 24. Teste 1 Introdução 2 Contexto 3 Organização para Realização de Testes 4 Executando Teste 5 Depurando Software 6 Técnicas de Teste Validação de Software – Módulo 1 Conceitos Básicos Transparência 24
  • 25. 1. Introdução 1.1 Engenharia de Software e Teste 1.2 O quê é teste 1.3 Objetivos da Atividade de Teste 1.4 Erros e as atividades de teste Validação de Software – Módulo 1 Conceitos Básicos Transparência 25
  • 26. 1.1 Engenharia de Software e Teste 1- Fase de Definição ("o que") - Análise do sistema - Planejamento do projeto de software - Análise de requisitos 2- Fase de Desenvolvimento ("como") - Projeto de software - Codificação - Realização de testes 3- Fase de Manutenção ("alterações") Validação de Software – Módulo 1 Conceitos Básicos Transparência 26
  • 27. 1.2 O Quê é Teste 1. a atividade de teste é o processo de executar um programa com a intenção de descobrir um erro 2. um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto 3. um teste bem-sucedido é aquele que revela um erro ainda não descoberto. Validação de Software – Módulo 1 Conceitos Básicos Transparência 27
  • 28. 1.3 Objetivos da Atividade de Teste Objetivo: projetar testes que descubram sistematicamente diferentes classes de erros e façam-no com uma quantidade de tempo e esforço razoável. Se a atividade de teste for conduzida com sucesso, ela descobrirá erros no software. • A atividade de teste não pode mostrar a ausência de bugs. • Ela só pode mostrar se defeitos de software estão presentes. Validação de Software – Módulo 1 Conceitos Básicos Transparência 28
  • 29. 1.4 Erros e as Atividades de Teste Se erros graves forem encontrados com regularidade, isto implica que a qualidade e a confiabilidade de software são suspeitas. Se erros facilmente corrigíveis forem encontrados, isto implica que a qualidade e a confiabilidade do software estão aceitáveis ou os testes são inadequados para revelar erros graves Se não for encontrado erro isto implica que a configuração de teste não foi suficientemente elaborada e erros estão escondidos no software Validação de Software – Módulo 1 Conceitos Básicos Transparência 29
  • 30. 1.5 O Processo de Teste Validação de Software – Módulo 1 Conceitos Básicos Transparência 30
  • 31. 2. Contexto 2.1 Princípios Básicos 2.2 Estratégia de Teste 2.3 Verificação e Validação 2.4 Garantia de Qualidade de Software Validação de Software – Módulo 1 Conceitos Básicos Transparência 31
  • 32. 2.1 Princípios Básicos Teste é um conjunto de atividades que pode ser planejado antecipadamente e realizado sistematicamente. - o planejamento e a realização das atividades de teste definem a estratégia de testes de software. - uma estratégia de teste de software define técnicas de projeto de casos de teste e métodos de teste específicos para cada etapa do processo de engenharia de software. Validação de Software – Módulo 1 Conceitos Básicos Transparência 32
  • 33. 2.2 Estratégia de Teste de Software Uma Estratégia de Teste deve acomodar testes de baixo nível e testes de alto nível, deve oferecer orientação ao profissional, deve oferecer um conjunto de marcos de referência ao administrador e deve ser mensurável. Validação de Software – Módulo 1 Conceitos Básicos Transparência 33
  • 34. Características das Estratégias de Teste (a) – a atividade de teste inicia-se no nível de módulos e prossegue "para fora", na direção da integração de todo o sistema – diferentes técnicas de teste são apropriadas a diferentes pontos de tempo. – a atividade de teste é realizada pela equipe de desenvolvimento do software e para grandes projetos por um grupo de teste independente. Validação de Software – Módulo 1 Conceitos Básicos Transparência 34
  • 35. Características das Estratégias de Teste (b) – as atividades de teste e de depuração são atividades diferentes, mas a depuração deve ser acomodada em qualquer estratégia de teste. – deve oferecer um conjunto de marcos de referência ao administrador e deve ser mensurável. Validação de Software – Módulo 1 Conceitos Básicos Transparência 35
  • 36. 2.3 Verificação e Validação (V&V) A atividade de teste de software é um elemento de um tema mais amplo chamado Verificação e Validação (V&V). A definição de V&V abrange muitas das atividades às quais nos referimos como Garantia da Qualidade de Software (SQA). Validação de Software – Módulo 1 Conceitos Básicos Transparência 36
  • 37. Verificação refere-se ao conjunto de atividades que garante que o software implementa corretamente uma função específica. “Estamos construindo certo o produto?” Validação de Software – Módulo 1 Conceitos Básicos Transparência 37
  • 38. Validação refere-se ao conjunto de atividades que garante que o software que foi construído é “rastreável” às exigências do cliente. “Estamos construindo o produto certo?” Validação de Software – Módulo 1 Conceitos Básicos Transparência 38
  • 39. 2.4 Garantia da Qualidade de Software – Métodos de Engenharia de Software: proporcionam a base a partir da qual a qualidade é construída. – Revisões Técnicas Formais: ajudam a garantir a qualidade do produto produzido como uma conseqüência de cada passo da engenharia de software. – Medição: ajudam a controlar cada elemento da configuração de software. Validação de Software – Módulo 1 Conceitos Básicos Transparência 39
  • 40. Garantia da Qualidade de Software (cont.) – Padrões e Procedimentos: ajudam a garantir a uniformidade. – Garantia de Qualidade de Software (SQA): põe em prática uma filosofia de qualidade total. – Teste: a qualidade pode ser avaliada. Validação de Software – Módulo 1 Conceitos Básicos Transparência 40
  • 41. Validação de Software – Módulo 1 Conceitos Básicos Transparência 41
  • 42. 3. Organização para Realização de Testes 3.1 Desenvolvedores x Testadores 3.2 Como as pessoas vêem os testes 3.3 O Grupo Independente de Teste 3.4 Etapas do Teste de Software 3.5 Critérios para Conclusão de Testes Validação de Software – Módulo 1 Conceitos Básicos Transparência 42
  • 43. 3.1 Desenvolvedores x Testadores Quando o teste se inicia há um conflito de interesses: –Desenvolvedores: interesse em demonstrar que o programa é isento de erros. –Responsáveis pelos testes: interesse em mostrar que o programa tem erros. Validação de Software – Módulo 1 Conceitos Básicos Transparência 43
  • 44. 3.2 Como as Pessoas Vêem os Testes Do ponto de vista psicológico, as pessoas vêem os testes com uma tarefa destrutiva: • Análise, Projeto e Codificação de Software são tarefas construtivas • Teste é tarefa destrutiva pois visa descobrir problemas Validação de Software – Módulo 1 Conceitos Básicos Transparência 44
  • 45. 3.3 Grupo Independente de Teste Para suprir o conflito de interesses existe o Grupo Independente de Testes (ITG). ITG faz parte da equipe de projeto de desenvolvimento de software, no sentido de estarem envolvidos durante o processo de especificação e continuam planejando e especificando procedimentos de teste ao longo de um grande projeto. Validação de Software – Módulo 1 Conceitos Básicos Transparência 45
  • 46. 3.4 Etapas do Teste de Software Testes de Unidade: cada módulo é testado individualmente garantindo que ele funcione adequadamente. Utiliza as técnicas de teste de caixa branca. branca Testes de Integração: os módulos são montados ou integrados para formarem um pacote de software. Utiliza principalmente as técnicas de teste de caixa preta. preta Testes de Alto Nível (validação e sistema): Os critérios de validação estabelecidos durante a análise de requisitos são testados. Verifica também se todos os elementos combinam-se adequadamente e se a função/ desempenho global do sistema é conseguida. Utiliza as técnicas de caixa preta. preta Validação de Software – Módulo 1 Conceitos Básicos Transparência 46
  • 47. Etapas do Teste de Software Validação de Software – Módulo 1 Conceitos Básicos Transparência 47
  • 48. 3.5 Critérios para Conclusão de Teste Quando realizamos testes, como saber se já testamos o suficiente? Respostas pragmáticas: Você jamais terá completado a atividade de teste; a carga simplesmente transfere-se do projetista para o cliente. Quando estiver sem tempo ou sem dinheiro. Validação de Software – Módulo 1 Conceitos Básicos Transparência 48
  • 49. Um Modelo Empírico (a) Modelo Logarítmico do Tempo de Execução de Poisson: intensidade de erros real pode ser traçada em relação a curva prevista. Validação de Software – Módulo 1 Conceitos Básicos Transparência 49
  • 50. Um Modelo Empírico (b) Validação de Software – Módulo 1 Conceitos Básicos Transparência 50
  • 51. 4 Executando Testes 4.1 Níveis de Testes 4.2 Teste de Unidade 4.3 Teste de Integração 4.4 Teste de Validação 4.5 Teste de Sistema Validação de Software – Módulo 1 Conceitos Básicos Transparência 51
  • 52. 4.1 Níveis de Teste Teste de Unidade: concentra-se em cada unidade do software, de acordo com o que é implementado no código fonte. Teste de Integração: concentra-se no projeto e na construção da arquitetura de software. Teste de Validação: em como o software que foi construído é validado em relação aos requisitos de software. Teste de Sistema: o software e outros elementos do sistema são testados como um todo. Validação de Software – Módulo 1 Conceitos Básicos Transparência 52
  • 53. Validação de Software – Módulo 1 Conceitos Básicos Transparência 53
  • 54. 4.2 Teste de Unidade Os Testes de Unidade concentram-se em cada unidade do software, de acordo com o que é implementado no código fonte. Validação de Software – Módulo 1 Conceitos Básicos Transparência 54
  • 55. O Que é Testado (a) a interface com o módulo é testada para ter a garantia de que as informações fluem para dentro e para fora da unidade de programa que se encontra sob teste a estrutura de dados local é examinada para ter a garantia de que dados armazenados temporariamente mantêm sua integridade durante todos os passos de execução. Validação de Software – Módulo 1 Conceitos Básicos Transparência 55
  • 56. O Que é Testado (b) as condições de limite são testadas para ter a garantia de que o módulo opera adequadamente nos limites estabelecidos para demarcarem ou restringirem o processamento. todos os caminhos independentes através da estrutura de controle são exercitados para ter a garantia de que todas as instruções de um módulo foram executadas pelo menos uma vez. Validação de Software – Módulo 1 Conceitos Básicos Transparência 56
  • 57. O Que é Testado (c) todos os caminhos de tratamento de erros são testados. Interface Estruturas de dados locais Condições limite Caminhos independentes Caminhos de tratamento de erros Casos de Teste Validação de Software – Módulo 1 Conceitos Básicos Transparência 57
  • 58. O Ambiente de Teste de Unidade (a) Uma vez que o módulo não é um programa individual, um software driver e/ou stub deve ser desenvolvido para cada unidade de teste. Validação de Software – Módulo 1 Conceitos Básicos Transparência 58
  • 59. O Ambiente de Teste de Unidade (b) Driver na maioria das aplicações é um programa principal que aceita dados de caso de teste, passa tais dados para o módulo a ser testado e imprime os dados relevantes. Stub ou programa simulado - serve para substituir módulos que estejam subordinados (chamados pelo) ao módulo a ser testado. Usa a interface do módulo subordinado, pode fazer manipulação de dados mínima, imprime verificação de entrada e retorna. Validação de Software – Módulo 1 Conceitos Básicos Transparência 59
  • 60. O Ambiente de Teste de Unidade (c) • Interface • Estruturas de dados locais Driver • Condições limites • Caminhos execução módulo a • Caminhos de tratamento ser testado de erros Resultados Stub 1 Stub 2 casos de teste Validação de Software – Módulo 1 Conceitos Básicos Transparência 60
  • 61. 4.3 Teste de Integração Os Testes de Integração concentram-se no projeto e na construção da arquitetura de software, almejam descobrir erros associados a interfaces. interfaces O objetivo é, a partir dos módulos testados ao nível de unidade, integrá-los, e testar se a estrutura de programa construída foi aquela determinada pelo projeto. Validação de Software – Módulo 1 Conceitos Básicos Transparência 61
  • 62. Validação de Software – Módulo 1 Conceitos Básicos Transparência 62
  • 63. Abordagens Integração não incremental: (abordagem “big-bang”) o programa completo é testado como um todo e o resultado é o caos. Quando erros são encontrados, a correção é difícil porque o isolamento das causas é complicado pela vasta amplitude do programa inteiro. Integração incremental: o programa é construído e testado em pequenos segmentos, onde os erros são mais fáceis de serem isolados e corrigidos; as interfaces têm maior probabilidade de serem testadas completamente e uma abordagem sistemática ao teste pode ser aplicada. Validação de Software – Módulo 1 Conceitos Básicos Transparência 63
  • 64. Integração Top-Down (a) Os módulos são integrados movimentando-se de cima para baixo, através da hierarquia de controle, iniciando-se do módulo de controle principal. Os módulos subordinados ao módulo de controle principal são incorporados à estrutura de uma maneira depth-first (primeiro pela profundidade) ou breadth-first (primeiramente pela largura). Validação de Software – Módulo 1 Conceitos Básicos Transparência 64
  • 65. Integração Top-Down (b) Validação de Software – Módulo 1 Conceitos Básicos Transparência 65
  • 66. Passos do Processo de Integração Top-Down (a) 1. o módulo de controle é usado como um driver de teste e os stubs são substituídos para todos os módulos diretamente subordinados ao módulo de controle principal. 2. dependendo da abordagem de integração escolhida, os stubs subordinados são substituídos, um de cada vez por módulos reais. 3. testes são realizados à medida que cada módulo é integrado. Validação de Software – Módulo 1 Conceitos Básicos Transparência 66
  • 67. Passos do Processo de Integração Top-Down (b) 4. durante a conclusão de cada conjunto de testes, outro stub é substituído pelo módulo real. 5. teste de regressão - (realização de todos ou de alguns dos testes anteriores) pode ser realizado a fim de garantir que novos erros não tenham sido introduzidos. Validação de Software – Módulo 1 Conceitos Básicos Transparência 67
  • 68. 4.4 Teste de Validação Os Testes de Validação concentram-se em como os requisitos estabelecidos como parte da análise de requisitos de software são validados em relação ao software que foi construído. Validação de Software – Módulo 1 Conceitos Básicos Transparência 68
  • 69. Validação de Software – Módulo 1 Conceitos Básicos Transparência 69
  • 70. Contexto Ao término da atividade de teste de integração, o software está completamente montado como um pacote, erros de interface foram descobertos e corrigidos e uma série final de testes de software - os testes de validação - pode iniciar- se. Validação de Software – Módulo 1 Conceitos Básicos Transparência 70
  • 71. Princípios (a) A validação é bem sucedida quando o software funciona de uma maneira razoavelmente esperada pelo cliente. A Especificação de Requisitos de Software contém os critérios de validação que formam a base para uma abordagem ao teste de validação. A validação do software é realizada por meio de uma série de testes de caixa preta que demonstram a conformidade com os requisitos. Validação de Software – Módulo 1 Conceitos Básicos Transparência 71
  • 72. Princípios (b) O plano e o procedimento de teste são projetados para garantir que: todos os requisitos funcionais são satisfeitos todos os requisitos de desempenho são conseguidos a documentação está correta outros requisitos são cumpridos: portabilidade, compatibilidade, remoção de erros e manutenabilidade Validação de Software – Módulo 1 Conceitos Básicos Transparência 72
  • 73. Revisão de Configuração Um elemento importante do processo de validação é a revisão de configuração ou auditoria O propósito dessa revisão é garantir que todos os elementos da configuração de software tenham sido adequadamente desenvolvidos, estão catalogados e têm os detalhes necessários para apoiar a fase de manutenção do ciclo de vida do software. Validação de Software – Módulo 1 Conceitos Básicos Transparência 73
  • 74. Validação de Software – Módulo 1 Conceitos Básicos Transparência 74
  • 75. Testes Alfa e Beta x Teste de Aceitação É virtualmente impossível que se preveja como o cliente realmente usará/reagirá a um programa (as instruções de uso podem ser mal-interpretadas, combinações estranhas de dados podem ser irregularmente usadas, saídas que pareciam claras ao analista podem ser ininteligíveis para um usuários, etc). Testes devem ser feitos para se saber isto. Existem duas famílias de testes com esta finalidade: – Testes de Aceitação – Testes Alfa e Testes Beta Validação de Software – Módulo 1 Conceitos Básicos Transparência 75
  • 76. Teste de Aceitação Usado quando o software é customizado para um cliente objetiva capacitar/permitir ao usuário final a validar todos os requisitos. pode variar de um test drive informal a uma série de testes planejados. Validação de Software – Módulo 1 Conceitos Básicos Transparência 76
  • 77. Testes Alfa e Beta (a) Usado quando o software é desenvolvido como um produto para muitos clientes, geralmente tem duas fases: Teste Alfa - é levado a efeito por um cliente nas instalações do desenvolvedor. O software é usado num ambiente controlado com o desenvolvedor "olhando sobre os ombros" do usuário e registrando erros e problemas de uso. Validação de Software – Módulo 1 Conceitos Básicos Transparência 77
  • 78. Testes Alfa e Beta (b) Teste Beta - é realizado nas instalações do cliente pelo usuário final do software. O desenvolvedor não está presente. O cliente registra os problemas (reais ou imaginários) que são encontrados e relata-os ao desenvolvedor a intervalos regulares. Validação de Software – Módulo 1 Conceitos Básicos Transparência 78
  • 79. 4.5 Teste de Sistema O software é apenas um elemento de um sistema baseado em computador mais amplo. O teste de sistema envolve uma série de diferentes testes, cujo propósito primordial é por completamente à prova o sistema baseado em computador. Validação de Software – Módulo 1 Conceitos Básicos Transparência 79
  • 80. Validação de Software – Módulo 1 Conceitos Básicos Transparência 80
  • 81. Um Problema Clássico no Teste de Sistema "apontar o dedo" - quando ocorre um erro, o desenvolvedor de um elemento do sistema culpa outro pelo problema. Validação de Software – Módulo 1 Conceitos Básicos Transparência 81
  • 82. Princípios O engenheiro de sistema deve antecipar os problemas potenciais da interface: 1. projetar caminhos de tratamento de erros que testem todas as informações que chegam de outros elementos do sistema. 2. realizar uma série de testes que simulem dados ruins ou outros erros em potencial na interface do software. 3. registrar os resultados de teste para usar como "prova" se alguém lhe apontar o dedo. 4. participar do planejamento e projeto dos testes do sistema para garantir que o software seja adequadamente testado. Validação de Software – Módulo 1 Conceitos Básicos Transparência 82
  • 83. Teste de Recuperação Muitos sistemas baseados em computador precisam recuperar-se de falhas e retomar o processamento dentro de um tempo previamente especificado. Em certos casos, o sistema deve tolerar falhas, isto é, o processamento de falhas não deve fazer com que uma função global de sistema cesse. Em outros casos, uma falha do sistema deve ser corrigida dentro de um período previamente especificado; caso contrário, graves prejuízos econômicos ocorrerão. O teste de recuperação é um teste de sistema que força o software a falhar de diversas maneiras e verifica se a recuperação é adequadamente executada. Validação de Software – Módulo 1 Conceitos Básicos Transparência 83
  • 84. Teste de Segurança (a) Qualquer sistema baseado em computador que gerencie informações delicadas ou provoque ações que possam impropriamente prejudicar (ou beneficiar) pessoas constitui um alvo para o acesso impróprio ou ilegal. O teste de segurança tenta verificar se todos os mecanismos de proteção embutidos num sistema o protegerão, de fato, de acessos indevidos. Validação de Software – Módulo 1 Conceitos Básicos Transparência 84
  • 85. Teste de Segurança (b) Durante o teste de segurança, o analista desempenha o papel de pessoa que deseja penetrar no sistema. Qualquer coisa vale! adquirir senhas mediante contatos externos atacar o sistema com software customizado projetado para derrubar quaisquer defesas que tenham sido construídas Validação de Software – Módulo 1 Conceitos Básicos Transparência 85
  • 86. Teste de Segurança (c) desarmar o sistema, negando serviço a outros provocar erros intencionalmente, esperando acessá-lo durante a recuperação "folhear" através de dados inseguros esperando descobrir a chave para a entrada no sistema. O papel do projetista do sistema é fazer com que o acesso custe mais do que o valor da informação que será obtida. Validação de Software – Módulo 1 Conceitos Básicos Transparência 86
  • 87. 5 Depurando Software 5.5.1 O Quê é depuração 5.5.2 Abordagens à depuração Validação de Software – Módulo 1 Conceitos Básicos Transparência 87
  • 88. 5.5.1 O Quê é Depuração O objetivo primordial da depuração ou debugging é descobrir e corrigir a causa de um erro de software. A depuração ocorre em conseqüência de testes bem sucedidos. Embora a depuração possa e deva ser ser um processo disciplinado, ela ainda tem muito de arte. Validação de Software – Módulo 1 Conceitos Básicos Transparência 88
  • 89. O Processo de Depuração Validação de Software – Módulo 1 Conceitos Básicos Transparência 89
  • 90. Severidade de Erros Durante a depuração, encontram-se erros que variam de brandamente perturbadores a catastróficos. À medida que as conseqüências de uma falha aumentam, a pressão para descobrir a causa também aumenta. Validação de Software – Módulo 1 Conceitos Básicos Transparência 90
  • 91. Por que a Depuração é Difícil? (a) 1) O sintoma e a causa podem ser geograficamente remotos. Estruturas altamente acopladas agravam essa situação. 2) O sintoma pode desaparecer (temporariamente) quando outro erro é corrigido. 3) O sintoma pode, de fato, ser causado por não erros (por exemplo, imprecisões de arredondamento). Validação de Software – Módulo 1 Conceitos Básicos Transparência 91
  • 92. Por que a Depuração é Difícil? (b) 4) O sintoma pode ser causado por um erro humano que não é facilmente rastreado. 5) O sintoma pode ser resultado de problemas de temporização, e não problemas de processamento. 6) O sintoma pode ser devido a causas que estão distribuídas por uma série de tarefas que são executadas em diferentes processadores. Validação de Software – Módulo 1 Conceitos Básicos Transparência 92
  • 93. 5.5.2 Abordagens à Depuração 1 - Força bruta 2 - Backtracking 3 - Eliminação da Causa Validação de Software – Módulo 1 Conceitos Básicos Transparência 93
  • 94. Força Bruta (a) A categoria de depuração por força bruta provavelmente é o método mais comum e menos eficiente de isolar a causa de um erro de software. Usa-se uma filosofia do tipo "deixe que o computador descubra o erro". Por exemplo, são feitas listagens de memória (memory dumps), são inseridas instruções WRITE, etc. Aplica-se o método de força bruta quando tudo o mais falha. Validação de Software – Módulo 1 Conceitos Básicos Transparência 94
  • 95. Força Bruta (b) Espera-se encontrar, em algum lugar do emaranhado de informações, uma pista que possa levar à causa de um erro. Não obstante, a massa de informações produzida possa levar ao sucesso, mais freqüentemente ela conduz a tempo e esforço desperdiçados. Deve-se gastar o raciocínio primeiro. Validação de Software – Módulo 1 Conceitos Básicos Transparência 95
  • 96. Backtracking Iniciando-se no local em que o sintoma foi descoberto, o código fonte é rastreado para trás (manualmente) até que o local da causa seja encontrado. É uma abordagem que pode ser usada com sucesso em pequenos programas. Infelizmente, à medida que o número de linhas de código aumenta, o número de potenciais caminhos de backtracking pode tornar-se incontrolavelmente alto. Validação de Software – Módulo 1 Conceitos Básicos Transparência 96
  • 97. Eliminação da Causa Os dados relacionados à ocorrência de erros são organizados para isolar potenciais causas. Uma "hipótese de causa" é imaginada e os dados são usados para provar ou refutar a hipótese. Alternativamente, uma lista de todas as causas possíveis é desenvolvida e testes são realizados para eliminar cada uma delas. Se os testes iniciais indicarem que uma hipótese de causa apresenta possibilidades, os dados são refinados, numa tentativa de isolar o bug. Validação de Software – Módulo 1 Conceitos Básicos Transparência 97
  • 98. 5.5.3 Dicas Sobre Depuração (a) As abordagens de depuração podem ser complementadas com ferramentas de depuração: compiladores de depuração, auxílio rastreadores de depuração dinâmicos, geradores de casos de teste automáticos, geradores de dumps de memória e geradores de mapas de referência cruzada. Validação de Software – Módulo 1 Conceitos Básicos Transparência 98
  • 99. Dicas Sobre Depuração (b) Um poderoso aliado à depuração são "outras pessoas". O conceito de “programação não egoística” deve ser ampliado para "depuração não egoística". Validação de Software – Módulo 1 Conceitos Básicos Transparência 99
  • 100. Dicas Sobre Depuração (c) Assim que um erro é encontrado, ele deve ser corrigido, porém a correção de um erro pode introduzir outros erros. Assim, deve- se fazer 3 perguntas simples, sempre que se realizar uma "correção" que removerá a causa de um erro: 1- A causa do bug é reproduzida em outra parte do programa? 2- Qual "bug seguinte" poderia ser introduzido pelo reparo que se está prestes a fazer? 3- O que poderia ter sido feito para eliminar este bug desde o princípio? Validação de Software – Módulo 1 Conceitos Básicos Transparência 100