SlideShare uma empresa Scribd logo
Testes de Software
Prof: Sérgio Souza Costa
Capítulo 12:
Estratégias de teste de software
Roteiro
• Conceitos de teste de software
• Atividades de teste de software
• Níveis de teste de software
Roteiro
• Conceitos de teste de software
• Atividades de teste de software
• Níveis de teste de software
Conceitos de testes de software
Conceitos de teste de software
Existe alguma diferença entre os termos
defeito, falha e erro ? Ou são sinónimos ?
Depurar é uma técnica de teste de software ?
Exemplo
O fechamento não esperado de um
programa.
O fechamento não esperado de um
   programa.




Durante um teste, ocorreu uma falha
A falha pode ser entendida
como consequencia.
Mas qual é a causa ?
Dica:

Programa foi codificado em C++.
Erro de acesso a memória
Depura-se para encontrar o defeito
Conceitos de testes de software
• A Falha foi o fechamento não esperado do
  software.

• O Erro foi um valor de endereço de memória
  inválido ou protegido.

• O Defeito, estava na codificação. Por
  exemplo, o programador esqueceu de
  inicializar uma variável.
Conceitos de testes de software
• O padrão IEEE número 610.12-1990
  – defeito (fault) – passo, processo ou definição de
    dados incorreto, como por exemplo, uma
    instrução ou comando incorreto,
  – erro (error) – diferença entre o valor obtido e o
    valor esperado, ou seja, qualquer estado
    intermediário incorreto ou resultado inesperado
    na execução do programa constitui um erro;
  – falha (failure) – produção de uma saída incorreta
    com relação á especificação.
Conceitos de testes de software

  Defeito           Erro           Falha

Defeitos podem ocasionar a manifestação de
erros.
               Erros podem gerar falhas.
Falha é um comportamento inesperado que
afeta diretamente o usuário.
Conceitos de testes de software
                            Uma falha pode ter sido
                            causada por diversos
                            erros e alguns erros
  Defeito           Erro               Falha
                            podem nunca causar
                            uma falha.

Defeitos podem ocasionar a manifestação de
erros.
               Erros podem gerar falhas.
Falha é um comportamento inesperado que
afeta diretamente o usuário.
Conceitos de testes de software
• Testes tem como objetivo causar falhas em um
  programa.
Conceitos de testes de software
• Testes tem como objetivo causar falhas em um
  programa.

• Depois do teste, precisamos encontrar e
  corrigir defeitos, ou seja, depurar.
Conceitos de testes de software
• Testes tem como objetivo causar falhas em um
  programa.

• Depois do teste, precisamos encontrar e
  corrigir defeitos, ou seja, depurar.


   Depurar não é testar
Conceitos de testes de software
Testes:
Processo de execução de um programa com o objetivo de
revelar a presença de falhas.
Contribuem para aumentar a confiança de que o software
desempenha as funções especificadas.


Depuração:
Consequência do teste. Após revelada a presença da falha, este
deve ser encontrado e corrigido.
Roteiro
• Conceitos de teste de software
• Atividades de teste de software
• Níveis de teste de software
Atividades de teste de software

Teste é um elemento de um aspecto mais
amplo, referido como verificação e validação
(V&V).
Atividades de teste de software

Teste é um elemento de um aspecto mais
amplo, referido como verificação e validação
(V&V).

Verificação e validação engloba muitas das
atividades que são abrangidas para garantia de
qualidade de software.
Atividades de teste de software
Verificação: Assegurar consistência, completitude e
corretude do produto em cada fase e entre fases
consecutivas do ciclo de vida do software.

     Estamos construindo corretamente o produto?
 Validação: Assegurar que o produto final corresponda aos
 requisitos do usuário.

          Estamos construindo o produto certo?
Teste: Examina o comportamento do produto por meio de sua
execução.
Atividades de teste de software


                       Verificação e validação
                       estão no nível D do
                       mpsBr.
Atividades de teste de software

“Testing can only show the presence of errors, not
their absence” (Dijkstra et al., 1972).


Testes podem somente mostrar a presença de
erros, não a sua ausência.
Atividades de teste de software

Objetivo do teste é causar uma falha, então a
inexistência de falha pode ser explicado por:

• Software é de alta qualidade?
• Os testes foram de baixa qualidade ?
Atividades de teste de software

                                  Testes          nunca
Objetivo do teste é causar uma falha, então a vez que
                                  terminam, toda
                                  o usuário utiliza um
inexistência de falha pode ser explicado por:
                                  programa, ele esta
                                  testando-o.
• Software é de alta qualidade?
• Os testes foram de baixa qualidade ?
Atividades de teste de software

                                     Testes de software
                             Se uma falha não é
Objetivo do teste é causar uma falha, então atoda vez
                                     nunca termina,
                             identificadaopela equipe um
                                     que usuário utiliza
inexistência de falha pode ser explicado por:
                             de      programa, ele esta
                             desenvolvimento, será
                                     testando-o.
                             identificada        pelo
• Software é de alta qualidade?
                             usuário.
• Os testes foram de baixa qualidade ?
Atividades de teste de software
• Para garantir a qualidade dos testes, estes
  devem ser feitos de forma sistemática, que
  inclui:
  1. Planejamento de testes,
  2. Projeto de casos de teste,
  3. Execução e avaliação dos resultados dos testes.
Planejamento de testes
• Planejar é distribuir racionalmente no tempo os
  recursos disponíveis para realizar alguma
  atividade.
• No caso de testes será gerado o plano de teste:
  –   Definir o método,
  –   Recursos necessários
  –   Cronograma de atividades
  –   Pessoal necessário
  –   O que será testado
  –   O que não será testado
  –   Responsáveis
Projeto de testes
• O projeto de casos de teste pode ser tão difícil
  quanto o projeto do próprio produto a ser testado.
• Poucos desenvolvedores gostam de teste e, menos
  ainda, do projeto de casos de teste
• Será escolhido um grupo específico de características
  a serem testadas. Descrevendo detalhadamente os
  métodos e testes que deverão ser executados.
• O resultado será o documento de caso de testes e o
  procedimento de teste.
Casos de testes
• Especificação de uma entrada para o
  programa e a correspondente saída esperada
  – Entrada: conjunto de dados necessários para uma
    execução do programa
  – Saída esperada: resultado de uma execução do
    programa
• Um bom caso de teste tem alta probabilidade
  de revelar uma falha ainda não descoberta.
Execução de teste
• Os casos de testes serão executados.
• Todo atividade de teste deve ser
  registrada, identificando:
  – Hora do teste
  – Procedimento
  – Pessoal envolvido
  – Resultados obtidos
  – Condições ambientais
  – Eventos não esperando (quando ocorrerem)
Roteiro
• Conceitos de teste de software
• Atividades de teste de software
• Níveis de teste de software
Quais as origens dos defeitos em
software ? Onde e quando eles
ocorrem ?
Defeitos no processo de desenvolvimento


Como o software é um produto lógico, defeitos são
de origem humana.
Defeitos no processo de desenvolvimento

Um software falha quando ele não esta de acordo com o
esperado pelo usuário. Lembrando que o esperado pelo
usuário não é necessariamente o que foi especificado de
modo que a falha de um sistema não esta relacionada
apenas a defeitos na codificação e ou projeto.

Os defeitos normalmente são introduzidos na transformação
de informações entre as diferentes fases do ciclo de
desenvolvimento de um software.
      Dos requisitos a codificação.
Defeitos no processo de desenvolvimento


                               As diversas transformações de
                               um requisito de software.
  Descrição
   textual

                Casos de uso

                                      Diagramas de
                                     classe, iteração


Defeitos tendem a aparecer e ou a                       Código
propagar durante as transformações
Defeitos no processo de desenvolvimento
                                       Muitos encontram-
                                       se em partes do
                               As diversas transformações de
                                       código raramente
                                       executadas
                               um requisito de software.
  Descrição
   textual

                Casos de uso

                                      Diagramas de
                                     classe, iteração


Defeitos tendem a aparecer e ou a                       Código
propagar durante as transformações
Níveis de teste de software
• Os testes devem ser executados em diferentes níveis, visando
  avaliar o software em diferentes perspectivas de acordo com
  o produto gerado em cada fase do ciclo de vida de
  desenvolvimento de um software (Pressman, ).
   – Testes de unidade: as menores unidades funcionam
     corretamente?
   – Testes de integração: quando integradas elas continuam a
     produzir o resultado esperado ?
   – Testes de validação: (ou aceitação) o programa produz o
     resultado esperado pelo usuário?
   – Testes de sistema: o programa funciona como esperado no
     seu ambiente como todo ?
Níveis de teste de software



      Testes de unidade

          Código
Níveis de teste de software


      Testes de integaçao

      Testes de unidade
          Código
          Projeto
Níveis de teste de software

      Testes de validação
      Testes de integaçao

      Testes de unidade
          Código
          Projeto
         Requisitos
Níveis de teste de software
        Teste de sistema
      Testes de validação
      Testes de integaçao

       Testes de unidade
           Código
           Projeto
          Requisitos
     Engenharia de sistemas
Níveis de teste de software

Teste de Regressão não corresponde a um nível de teste, mas
é uma estratégia importante para redução de “efeitos
colaterais”.

Consiste em se aplicar, a cada nova versão do software ou a
cada ciclo, todos os testes que já foram aplicados nas versões
ou ciclos de teste anteriores do sistema.

Pode ser aplicado em qualquer nível de teste.
Testes de unidade
• Tem como proposito testar a menor unidade
  do programa.
• Usa-se a descrição do projeto no nível da
  unidade como guia para os testes.
• Os erros estarão nos limites destas unidades.
• Pode ser conduzido em paralelo para diversas
  unidades.
Testes de unidade



Unidade            Interface
                   Estruturas de dados
                   Condições limites
                   Caminhos independentes
                   Caminhos de manipulação de erros




                                Casos de teste
Testes de unidade
• Interface, é testada para garantir que a informação flui
  adequadamente para dentro e para fora da unidade do
  programa.
• Estrutura de dados, é examinada para garantir que os
  dados armazenados temporariamente mantenham sua
  integridade durante todos os passos do programa.
• As condições-limites são testadas para garantir que a
  unidade opere adequadamente nos limiares.
• Todos os caminhos independentes (básicos) são exercitados
  para garantir que que todos os comandos tenham sido
  executados
• Todos os caminhos de manipulação de erros são testados.
Testes de unidade
• Interface, é testada para garantir que a informação flui
  adequadamente para dentro e para fora da unidade do
  programa.
• Estrutura de dados, é examinada para garantir que os
  dados armazenados temporariamente mantenham sua
  integridade durante todos os passos do programa.
• As condições-limites são testadas para garantir que a
  unidade opere adequadamente nos limiares.
• Todos os caminhos independentes (básicos) são exercitados
  para garantir que que todos os comandos tenham sido
  executados
• Todos os caminhos de manipulação de erros são testados.
Testes de unidade: Interface
• Testes de fluxo de dados entre as interfaces
  são necessários antes de qualquer outro teste.

• Se os dados não entram e nem saem
  adequadamente, todo os testes são
  discutíveis.
Testes de unidade: ED
• As estruturas de dados (ED) locais devem ser
  exercitadas

• O impacto local nos dados globais devem ser
  verificados (se possível) durante o teste de
  unidade.
Teste de unidade: teste de caminho
• Casos de testes devem ser projetados para
  descobrir erros devidos a cálculos
  errados, comparações incorretas ou fluxo de
  controle inadequado.
• Exemplos:
  – Inicialização incorreta, representação incorreta de
    uma expressão, erros de operadores ou
    precedência, variáveis de ciclo inadequadamente
    modificada e etc
Teste de unidade: limites
• Teste nos limites é uma das mais importantes
  tarefas do teste de unidade.
• O software frequentemente falha nos limites:
  – N-esimo elemento de um vetor de dimensão N é
    processado, a I-esima repetição de um ciclo com I
    passagens, valor máximo ou mínimo é encontrado
    e etc.
Teste de unidade: exceção
• Erros potenciais no tratamento de erro (ou
  exceção):
  1. Descrição de erro ininteligível
  2. Erro mencionado não corresponde ao erro
     encontrado
  3. A condição de erro provoca a intervenção do
     sistema antes da manipulação de erro
  4. O processamento da condição de exceção de erro
     esta incorreto.
  5. A descrição de erro não fornece informação
     suficiente para encontrar o defeito
Testes de unidade: procedimento
• Normalmente considerado um apêndice ao
  passo de codificação.
• O projeto de teste pode ser realizado antes
  que o código seja iniciado (abordagem ágil)
• Cada cada caso de teste deve ser acoplado a
  um conjunto de resultados esperados.
São capazes de identificar um desafio
prático com relação aos testes de
unidade?
Testes de unidade: procedimento
• Uma unidade não é um programa isolado, o
  software para um pseudocontrolador (driver)
  e ou pseudocontrolado (stub) precisa ser
  desenvolvido para cada caso de teste.
  – Em muitos casos o pseudocontrolador será apenas
    um programa principal, que aceita dados do caso
    de teste e passa para unidade.
  – Pseudocontrolado substitui unidades
    subordinados a unidade a ser testada.
Testes de unidade: procedimento
                             Pseudocontroladores e
•   Uma unidade não é um programa isolado, são
                             pseudocontrolados o
                             despesas indiretas.
    software para um pseudocontrolador (driver)
    e ou pseudocontrolado (stub) precisa ser
    desenvolvido para cada caso de teste.
    – Em muitos casos o pseudocontrolador será apenas
      um programa principal, que aceita dados do caso
      de teste e passa para unidade.
    – Pseudocontrolado substitui unidades
      subordinados a unidade a ser testada.
Testes de unidade: procedimento
                               Pseudocontroladores e
•   Uma unidade não é um programa isolado, são
                               pseudocontrolados o
                          Em alguns casos pode
                               despesas indiretas.
    software para um pseudocontrolador (driver)
                          não valer a pena
    e ou pseudocontroladodesenvolvê-los, tendo
                           (stub) precisa ser
    desenvolvido para cadaque adiar osteste.
                           caso de testes.
    – Em muitos casos o pseudocontrolador será apenas
      um programa principal, que aceita dados do caso
      de teste e passa para unidade.
    – Pseudocontrolado substitui unidades
      subordinados a unidade a ser testada.
Como a alta coesão de uma unidade
pode afetar o teste de unidade?
Testes de unidade: procedimento
• Testes de unidades são simplificados em
  componentes com alta coesão.
• Quando uma única função é implementada o
  número de casos de testes é reduzido e os
  erros podem ser mais facilmente previstos e
  descobertos.
Testes de unidade: procedimento
• Testes de unidades são simplificados em
                        Por isso o teste de
  componentes com altaprogramas escritos em
                          coesão.funcionais
                        linguagens
• Quando uma única função Haskell tendem a ser o
                        como é implementada
  número de casos de testesfáceis. A disciplina os
                        mais é reduzido e
                        destas linguagens torna as
  erros podem ser mais facilmente previstos e
                        funções altamente coesas.
  descobertos.
Testes de unidade

• Os testes de unidade em linguagens
  funcionais, como Haskell, focam nas funções.
• Em linguagens procedurais como C, os testes
  de unidades são em procedimentos.
Testes de unidades

Em linguagens orientadas a objetos, os testes de
unidades podem focar apenas nos métodos
isoladamente ?
Testes de unidade em OO
• Considerem uma hierarquia de classe, na qual
  uma operação X é definida para uma
  superclasse e herdada por várias subclasses.
• A operação X será aplicada sobre diferentes
  contextos.
• Precisamos testar a operação X como parte de
  uma classe.
Se minhas unidades funcionam como o
esperado, não significa que meu software
irá funcionar como o esperado ?
Testes de integração
• Infelizmente, software é um sistema
  complexo. Defeitos de projetos podem:
  – Perder dados entre as interfaces (ex: dados
    incompátiveis)
  – Efeito imprevisto ou adverso sobre o outro (ex:
    variáveis globais)
  – Subfunções quando integradas podem não
    produzir o resultado esperado pela função
    principal.
  – etc
Testes de integração
• Infelizmente, software é um sistema
  complexo. DefeitosAde projetosdas
                       imutabilidade
                                      podem:
                     variáveis em linguagem
  – Perder dados entrefuncional tende a evitar
                        as interfaces (ex: dados
    incompátiveis)     algumas das falhas
                       relacionadas a integração.
  – Efeito imprevisto ou adverso sobre o outro (ex:
    variáveis globais)
  – Subfunções quando integradas podem não
    produzir a função principal.
  – etc
Testes de integração
• Técnica sistemática para construir a
  arquitetura do software e ao mesmo
  tempo, conduz testes para descobrir falhas
  associadas a interface.
• Abordagens:
  – a) Não incremental e b) incremental
Testes de integração: não incremental
• A integração não incremental, ou seja, a
  abordagem big-bang.
  – Todos os componentes são integrados e o sistema
    é testado.
  – Não existe uma abordagem sistemática para
    integração
• Abordagem caótica, um conjunto de falhas é
  identificada e a correção é difícil, pois o
  isolamento das causas é complicado.
Testes de integração: não incremental
• A integração não incremental, ou seja, a
                        Para os que já fizeram
  abordagem big-bang. disciplina de
                           programação comigo.
   – Todos os componentes sãofez lembrar de algoo sistema
                           Isto integrados e
     é testado.            que eu sempre falo para
                           vocês ?
   – Não existe uma abordagem sistemática para
     integração
• Abordagem caótica, um conjunto de falhas é
  identificada e a correção é difícil, pois o
  isolamento das causas é complicado.
Testes de integração: incremental
• Antítese da abordagem big-bang. O programa é
  construído e testado em pequenos incrementos, em
  que os erros são mais fáceis de isolar e corrigir:
   – Integração descendente (top-down), as unidades são
     integradas movendo descendentemente pela
     hierarquia, começa pela unidade principal(programa
     principal) e dela as unidades subordinadas.
   – Integração ascendente (bottom-up), inicia o teste com as
     unidades atômicas (níveis mais baixos do programa) e são
     integrados de baixo para cima.
Integração top-down
 Primeiro-em-profundidade vs Primeiro-em-largura


                   M1


     M2            M3                M4


M5        M6       M7


M8
Integração top-down
 Primeiro-em-profundidade vs Primeiro-em-largura


                   M1


     M2            M3                  M4
                               Lembraram
                               de busca em
                               grafo ?
M5        M6       M7


M8
Integração top-down
1. O modulo principal é usado como pseudocontrolador
   do teste, e pseudocontrolados sao substituídos pelas
   unidades subordinadas.
   – Primeiro-em-largura ou primeiro-em-profundidade.
2. Testes sao conduzidos a medida que cada componente
   é integrado
3. Ao término de cada conjunto de testes, outro
   pseudocontrolado é substituído pela unidade real.
4. Testes de regressão podem ser conduzidos para garantir
   que novos erros (efeitos colaterais) não tenham sido
   introduzidos.
Qual problema com relação a
integração top-down ?
Integração top-down
• O processamento de níveis baixos da
  hierarquia são necessários para testar os
  níveis superiores. Soluções:
  1. Adiar muitos testes
  2. Desenvolver pseudocontrolados
  3. Integrar o software de baixo para cima.
Integração bottom-up

• Os componentes são integrados de baixo para
  cima, as unidades subordinadas estão sempre
  disponíveis.
• Necessidades de pseudocontrolados é
  eliminada.
• Pseudocontroladores são necessários.
Integração bottom-up
1. Componentes de baixo nível são combinados em agregados
   (clusters, algumas vezes chamados de construções) que
   realizam uma subfunção especifica.
2. Um pseudocontrolador é escrito para coordenar a entrada e
   a saída dos casos de teste
3. O agregado e testado.
4. Pseudocontroladores são removidos e agregados são
   combinados movendo-se para cima da estrutura do
   programa.
Integraçao bottom-up
                                   Uc


      Pseudocontroladores
                            Ua                Ub



                       P1           P2             P3




                                                        Agregado 3
Agregado 1




                                 Agregado 2
E os testes de integração, o uso de orientação a
objeto tem algum impacto sobre as abordagens
descendentes (top-down) e ascendente (bottom-up)
?
Testes de integração em OO
• Em OO os objetos se relacionam e colaboram em
  tempo de execução de modo não obvio.
• A abordagem convencional não é efetiva.
• Duas estratégias:
  – Testes baseados na execução, integra um conjunto de
    classes necessárias para responde uma entrada ou um
    evento do sistema.
  – Testes baseado no uso uso, testam as classes
    independentes e depois as dependentes.
Testes de integração em OO
• Em OO os objetos se relacionam e colaboram em
  tempo de execução de modo não obvio.
• A abordagem convencional que oé efetiva.
                    Observem
                              não uso de
                    um paradigma tem
• Duas estratégias: impacto em todo o
                      processo de
  – Testes baseados na execução, integra um conjunto de
                      desenvolvimento.
    classes necessárias para responde uma entrada ou um
    evento do sistema.
  – Testes baseado no uso uso, testam as classes
    independentes e depois as dependentes.
Testes de validação
• Começa no fim do teste de integração, quando
  o software está completamente montado.
• Na validação não existe distinção de
  paradigmas.
• O teste focaliza ações visíveis ao usuário e
  saídas do sistema reconhecida pelo usuário.
Testes de validação
• Uma validação se torna bem
  sucedida, quando o software funciona de
  modo que pode ser razoavelmente esperado
  pelo usuário (Pressman).
Testes de validação
• Uma validação se torna bem
  sucedida, quando o software funciona de
  modo que pode ser razoavelmente esperado
  pelo usuário (Pressman).
• Expectativas razoáveis são definidas nas
  especificações de requisitos de software.
Testes de validação
• Uma validação se torna bem
  sucedida, quando o software funciona de
                  Lembrem-se, requisitos
  modo que podesempre mudam, e
                   ser razoavelmente esperado
  pelo usuário (Pressman). capturam a
                  dificilmente
                  real necessidade do
• Expectativas razoáveis são definidas nas
                  usuário.
  especificações de requisitos de software.
Testes de validação
• Como os requisitos mudam, abordagens modernas
  (incluindo os métodos ágeis) optam por entregar
  incrementos validáveis ao usuário com maior
  frequência.
• Isso permite encontrar desvios nas especificações
  mais cedo durante o ciclo do software.
Testes de validação
• Como os requisitos mudam, abordagens modernas
  (incluindo os métodos ágeis) optam e entregar
                    Processos iterativos por
  incrementos validáveis ao usuárioé
                    incrementais não com maior
  frequência.       exclusividade dos
                    métodos ágeis. Eles
• Isso permite encontrar desvios nas de
                    existem bem antes
                                        especificações
  mais cedo durantemuitos dos métodos
                     o ciclo do software.
                     ágeis surgirem.
Testes de validação
• Testes com os usuários: teste alfa e beta:

• Teste alfa, o usuário testa o software na presença do
  desenvolvedor. Os desenvolvedores podem anotar as
  falhas.

• Testes beta, o usuário testa o software em seu
  ambiente real. Neste caso os clientes que registram
  as falhas de software
Testes de sistema
• O software é apenas um elemento de um
  sistema maior baseado em computador.
  – Hardware, pessoas e informação.
• Testes de sistema é na verdade uma série de
  diferentes testes, cuja finalidade principal é
  exercitar por completo o sistema baseado em
  computador.
  – Testes de recuperação, testes de segurança, testes
    de estresse e testes de desempenho.
Testes de sistema: Testes de
                recuperação
• O sistema é tolerante a falha ? Falhas no sistema não
  podem causar interrupção da função global do
  sistema.
• Teste de recuperação força um software falhar e
  verifica:
   – A recuperação é automática?
   – A integridade dos dados são mantidas?
   – O tempo de recuperação (e ou reparo) está em tempo
     aceitável.
Testes de sistema: teste de segurança
• Testes de segurança verifica se os mecanismos de
  proteção incorporados a um sistema vão de fato
  protegê-lo de invasão imprópria.

• O testador desempenha o papel do indíviduo que
  deseja invadir o sistema. Vale tudo!
   –   Tentar obter ou descobrir senhas
   –   Usar software especialista para intrusão
   –   Causar falhas para tentar invadi-lo durante a recuperação.
   –   etc
Testes de sistema: teste de segurança
• Testes de segurança verifica se os mecanismos de
  proteção incorporados a um sistema vão de fato
  protegê-lo de invasão imprópria.
                    O bom teste vai acabar
                       invadindo o sistema. O
                       bom projeto vai tornar
• O testador desempenha o papel do indívido que
                       o custo maior que o
  deseja invadir o sistema. informação a
                       valor da Vale tudo!
   – Tentar obter ou descobrir senhas
                       ser obtida.
   – Usar software especialista para intrusão
   – Causar falhas para tentar invadi-lo durante a recuperação.
   – etc
Teste de estresse
• Testes de estresse executa um sistema de tal
  forma que a demanda de recursos em
  quantidade, frequência ou volume são
  anormais.
• Por exemplo:
  – a) Velocidade de entrada de dados pode ser
    aumentada, b) casos de teste que exigem o
    máximo de memória ou outros recursos, c) busca
    excessivas de dados em disco ...
Teste de estresse
• Testes de estresse executa um sistema de tal
  forma que a demanda de recursos em
                  O testador irá a todo
  quantidade, frequência ou volume são
  anormais.       custo tentar quebrar
                  o sistema.
• Por exemplo:
  – a) Velocidade de entrada de dados pode ser
    aumentada, b) casos de teste que exigem o
    máximo de memória ou outros recursos, c) busca
    excessivas em dados em disco ...
Teste de desempenho
• O teste de desempenho é projetado para testar o
  desempenho de um sistema integrado.
• O teste ocorre ao longo de todos os passos do
  processo de teste.
• Mesmo no nível de unidade pode ser avaliado a
  medida que testes são conduzidos.
  – O verdadeiro desempenho de um sistema não pode
    ser avaliado antes que todos os sistemas estejam
    plenamente integrados.
• Testes de desempenho são frequentemente
  acoplados a testes de estresse.
Pontos chaves
• Defeitos podem ocasionar a manifestação de
  erros.
• Erros podem gerar falhas.
• Falha é um comportamento inesperado que
  afeta diretamente o usuário
• Testes tem como objetivo causar falhas em um
  programa.
• Depuracao tem como objetivo encontrar um
  defeito de codificação
Pontos chaves
• Teste é uma atividade relacionada ao processo de
  verificação e validação, que por sua vez faz parte do
  processo de garantia de qualidade de software.
• Para ascender ao nivel D do mpsBr, é necessário
  haver um processo sistemático de testes de
  software.
• Defeitos de software podem ocorrer em qualquer
  fase, da especificação a codificação.
Pontos chaves
• Os níveis de testes são: testes de
  unidade, integração, validação e de sistema.
• Os testes de unidade testam a menor unidade do
  programa.
• Os testes de integração testam a integração
  destas unidades.
• Testes de validação testam se o programa se
  comporta como o esperado pelo usuário.
• Testes de sistema testa o sistema como
  todo, incluindo hardware, pessoas e informação.
Pontos chaves
• O uso de um paradigma de desenvolvimento
  afeta o procedimento de testes.
• Testes são muito importantes para garantir a
  qualidade de um software, porém tem um alto
  custo.
• Testes realizados de modo informal, tendem ser
  apenas um custo extra, sem garantia de melhoria
  na qualidade.
  – Testes devem ser realizados de maneira sistemática
Próxima aula

Próxima exercitaremos a escrita de casos de uso
com o projeto que estamos trabalhando
durante todo o curso.
Exercícios

Mais conteúdo relacionado

Mais procurados

Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade
Camilo Ribeiro
 
Qualidade de software
Qualidade de softwareQualidade de software
Qualidade de software
Alvaro Oliveira
 
Teste de software
Teste de softwareTeste de software
Teste de software
Rafael Sanches
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
Cloves da Rocha
 
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
 
Teste de software
Teste de softwareTeste de software
Teste de software
COTIC-PROEG (UFPA)
 
Fundamentos de Testes de Software
Fundamentos de Testes de SoftwareFundamentos de Testes de Software
Fundamentos de Testes de Software
Álvaro Farias Pinheiro
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
Tiago Antônio da Silva
 
Introdução ao design de teste de software
Introdução ao design de teste de softwareIntrodução ao design de teste de software
Introdução ao design de teste de software
Kleitor Franklint Correa Araujo
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
Leinylson Fontinele
 
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
 
Testes Funcionais
Testes FuncionaisTestes Funcionais
Testes Funcionais
Juliana Maria Lopes
 
Modelo plano de_testes
Modelo plano de_testesModelo plano de_testes
Modelo plano de_testes
Isaias Silva
 
Ferramentas para testes de software
Ferramentas para testes de softwareFerramentas para testes de software
Ferramentas para testes de software
Norton Guimarães
 
Exemplo de Plano de testes
Exemplo de Plano de testes Exemplo de Plano de testes
Exemplo de Plano de testes
Leandro Rodrigues
 
Conceitos de básicos de qualidade de software
Conceitos de básicos de qualidade de softwareConceitos de básicos de qualidade de software
Conceitos de básicos de qualidade de software
Ronney Moreira de Castro
 
Banco de questões qualidade de software
Banco de questões qualidade de softwareBanco de questões qualidade de software
Banco de questões qualidade de software
Bruno Nascimento
 
Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitos
elliando dias
 
Teste de software - aula 01 (motivação)
Teste de software - aula 01 (motivação)Teste de software - aula 01 (motivação)
Teste de software - aula 01 (motivação)
Elmano Cavalcanti
 
Teste de software - Conhecendo e Aplicando
Teste de software - Conhecendo e AplicandoTeste de software - Conhecendo e Aplicando
Teste de software - Conhecendo e Aplicando
André Phillip Bertoletti
 

Mais procurados (20)

Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade
 
Qualidade de software
Qualidade de softwareQualidade de software
Qualidade de software
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
 
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
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
Fundamentos de Testes de Software
Fundamentos de Testes de SoftwareFundamentos de Testes de Software
Fundamentos de Testes de Software
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
 
Introdução ao design de teste de software
Introdução ao design de teste de softwareIntrodução ao design de teste de software
Introdução ao design de teste de software
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade 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
 
Testes Funcionais
Testes FuncionaisTestes Funcionais
Testes Funcionais
 
Modelo plano de_testes
Modelo plano de_testesModelo plano de_testes
Modelo plano de_testes
 
Ferramentas para testes de software
Ferramentas para testes de softwareFerramentas para testes de software
Ferramentas para testes de software
 
Exemplo de Plano de testes
Exemplo de Plano de testes Exemplo de Plano de testes
Exemplo de Plano de testes
 
Conceitos de básicos de qualidade de software
Conceitos de básicos de qualidade de softwareConceitos de básicos de qualidade de software
Conceitos de básicos de qualidade de software
 
Banco de questões qualidade de software
Banco de questões qualidade de softwareBanco de questões qualidade de software
Banco de questões qualidade de software
 
Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitos
 
Teste de software - aula 01 (motivação)
Teste de software - aula 01 (motivação)Teste de software - aula 01 (motivação)
Teste de software - aula 01 (motivação)
 
Teste de software - Conhecendo e Aplicando
Teste de software - Conhecendo e AplicandoTeste de software - Conhecendo e Aplicando
Teste de software - Conhecendo e Aplicando
 

Destaque

Testes De Software - Uma Visão Geral
Testes De Software - Uma Visão GeralTestes De Software - Uma Visão Geral
Testes De Software - Uma Visão Geral
paulo peres
 
Testes de Software & Ferramentas de Testes
Testes de Software & Ferramentas de TestesTestes de Software & Ferramentas de Testes
Testes de Software & Ferramentas de Testes
Paulo César M Jeveaux
 
Testes de Software - Fundamentos
Testes de Software - FundamentosTestes de Software - Fundamentos
Testes de Software - Fundamentos
Lucas Amaral
 
Projeto Aplicado 4°Ciclo Grp01 Testes De Software
Projeto Aplicado 4°Ciclo Grp01 Testes De SoftwareProjeto Aplicado 4°Ciclo Grp01 Testes De Software
Projeto Aplicado 4°Ciclo Grp01 Testes De Software
Luiz Nakazone
 
Testes de software
Testes de softwareTestes de software
Testes de software
Fernando Palma
 
Engenharia de Software Pressman
Engenharia de Software PressmanEngenharia de Software Pressman
Engenharia de Software Pressman
Simoneinfo
 
Engenharia de Testes
Engenharia de TestesEngenharia de Testes
Engenharia de Testes
UFPA
 
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
 
Testes Unitários
Testes UnitáriosTestes Unitários
Testes Unitários
Jadson Santos
 
Engenharia de software 7° edição roger s.pressman capítulo 1
Engenharia de software 7° edição roger s.pressman capítulo 1Engenharia de software 7° edição roger s.pressman capítulo 1
Engenharia de software 7° edição roger s.pressman capítulo 1
Lindomar ...
 
Técnicas de modelagem de teste (parte 2)
Técnicas de modelagem de teste (parte 2)Técnicas de modelagem de teste (parte 2)
Técnicas de modelagem de teste (parte 2)
Fabrício Campos
 
Técnicas de modelagem de teste (parte 1)
Técnicas de modelagem de teste (parte 1)Técnicas de modelagem de teste (parte 1)
Técnicas de modelagem de teste (parte 1)
Fabrício Campos
 
Exibri Software Product Lines Aosd
Exibri Software Product Lines AosdExibri Software Product Lines Aosd
Exibri Software Product Lines AosdCédric WILLIAMSON
 
Präsentation PM Forum - Social Software
Präsentation PM Forum  - Social SoftwarePräsentation PM Forum  - Social Software
Präsentation PM Forum - Social Software
GPMS
 
Présentation update crm lsi
Présentation update crm lsi Présentation update crm lsi
Présentation update crm lsi
SaaS Guru
 
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-ToolsSoftware-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Andreas Schreiber
 
2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...
2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...
2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...
Ayelt Komus
 
Découvrez les solutions de virtualisation de Stockage DataCore et sa platefor...
Découvrez les solutions de virtualisation de Stockage DataCore et sa platefor...Découvrez les solutions de virtualisation de Stockage DataCore et sa platefor...
Découvrez les solutions de virtualisation de Stockage DataCore et sa platefor...ljaquet
 
Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...
Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...
Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...
Club Alliances
 
FABIS Produktmanagement im CRM integriert
FABIS Produktmanagement im CRM integriertFABIS Produktmanagement im CRM integriert
FABIS Produktmanagement im CRM integriert
FABIS Sales Solutions GmbH & Co. KG
 

Destaque (20)

Testes De Software - Uma Visão Geral
Testes De Software - Uma Visão GeralTestes De Software - Uma Visão Geral
Testes De Software - Uma Visão Geral
 
Testes de Software & Ferramentas de Testes
Testes de Software & Ferramentas de TestesTestes de Software & Ferramentas de Testes
Testes de Software & Ferramentas de Testes
 
Testes de Software - Fundamentos
Testes de Software - FundamentosTestes de Software - Fundamentos
Testes de Software - Fundamentos
 
Projeto Aplicado 4°Ciclo Grp01 Testes De Software
Projeto Aplicado 4°Ciclo Grp01 Testes De SoftwareProjeto Aplicado 4°Ciclo Grp01 Testes De Software
Projeto Aplicado 4°Ciclo Grp01 Testes De Software
 
Testes de software
Testes de softwareTestes de software
Testes de software
 
Engenharia de Software Pressman
Engenharia de Software PressmanEngenharia de Software Pressman
Engenharia de Software Pressman
 
Engenharia de Testes
Engenharia de TestesEngenharia de Testes
Engenharia de 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
 
Testes Unitários
Testes UnitáriosTestes Unitários
Testes Unitários
 
Engenharia de software 7° edição roger s.pressman capítulo 1
Engenharia de software 7° edição roger s.pressman capítulo 1Engenharia de software 7° edição roger s.pressman capítulo 1
Engenharia de software 7° edição roger s.pressman capítulo 1
 
Técnicas de modelagem de teste (parte 2)
Técnicas de modelagem de teste (parte 2)Técnicas de modelagem de teste (parte 2)
Técnicas de modelagem de teste (parte 2)
 
Técnicas de modelagem de teste (parte 1)
Técnicas de modelagem de teste (parte 1)Técnicas de modelagem de teste (parte 1)
Técnicas de modelagem de teste (parte 1)
 
Exibri Software Product Lines Aosd
Exibri Software Product Lines AosdExibri Software Product Lines Aosd
Exibri Software Product Lines Aosd
 
Präsentation PM Forum - Social Software
Präsentation PM Forum  - Social SoftwarePräsentation PM Forum  - Social Software
Präsentation PM Forum - Social Software
 
Présentation update crm lsi
Présentation update crm lsi Présentation update crm lsi
Présentation update crm lsi
 
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-ToolsSoftware-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
 
2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...
2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...
2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...
 
Découvrez les solutions de virtualisation de Stockage DataCore et sa platefor...
Découvrez les solutions de virtualisation de Stockage DataCore et sa platefor...Découvrez les solutions de virtualisation de Stockage DataCore et sa platefor...
Découvrez les solutions de virtualisation de Stockage DataCore et sa platefor...
 
Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...
Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...
Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...
 
FABIS Produktmanagement im CRM integriert
FABIS Produktmanagement im CRM integriertFABIS Produktmanagement im CRM integriert
FABIS Produktmanagement im CRM integriert
 

Semelhante a Teste de Software

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
 
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
 
Aula - Teste de Software
Aula - Teste de SoftwareAula - Teste de Software
Aula - Teste de Software
Mauricio Cesar Santos da Purificação
 
Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1
Fernando Palma
 
Gerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxGerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptx
Roberto Nunes
 
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
 
Qualidade de Software - Desenvolvimento dirigido por testes
Qualidade de Software - Desenvolvimento dirigido por testesQualidade de Software - Desenvolvimento dirigido por testes
Qualidade de Software - Desenvolvimento dirigido por testes
Joaquim Lopes Júnior
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
Roberto Espinha
 
SLIDEPRELIMINAR.pptx
SLIDEPRELIMINAR.pptxSLIDEPRELIMINAR.pptx
SLIDEPRELIMINAR.pptx
GustavoRondini
 
3 engenharia de software
3   engenharia de software3   engenharia de software
3 engenharia de software
Felipe Bugov
 
TesteDeSoftware_WorkshopSINFO2014.pdf
TesteDeSoftware_WorkshopSINFO2014.pdfTesteDeSoftware_WorkshopSINFO2014.pdf
TesteDeSoftware_WorkshopSINFO2014.pdf
Bruno Zolotareff dos Santos
 
Aula18_V&VTesteSoftware.pdf
Aula18_V&VTesteSoftware.pdfAula18_V&VTesteSoftware.pdf
Aula18_V&VTesteSoftware.pdf
MichaelArrais1
 
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
 
Gerenciamento da Qualidade de Software 3.pptx
Gerenciamento da Qualidade de Software 3.pptxGerenciamento da Qualidade de Software 3.pptx
Gerenciamento da Qualidade de Software 3.pptx
Roberto Nunes
 
Teste de software
Teste de softwareTeste de software
Teste de software
Claudio Eckert
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
testedesoftwarepe
 
Eng de testes
Eng de testesEng de testes
Eng de testes
GrupoAlves - professor
 
Qualidade de software com Visual Studio ALM
Qualidade de software com Visual Studio ALMQualidade de software com Visual Studio ALM
Qualidade de software com Visual Studio ALM
Adriano Bertucci
 
Aula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptxAula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptx
AlexandreLisboadaSil
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
Wagner Zaparoli
 

Semelhante a Teste de Software (20)

Introdução a testes de sofwtare
Introdução a testes de sofwtareIntrodução a testes de sofwtare
Introdução a testes de sofwtare
 
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
 
Aula - Teste de Software
Aula - Teste de SoftwareAula - Teste de Software
Aula - Teste de Software
 
Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1
 
Gerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxGerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptx
 
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
 
Qualidade de Software - Desenvolvimento dirigido por testes
Qualidade de Software - Desenvolvimento dirigido por testesQualidade de Software - Desenvolvimento dirigido por testes
Qualidade de Software - Desenvolvimento dirigido por testes
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
 
SLIDEPRELIMINAR.pptx
SLIDEPRELIMINAR.pptxSLIDEPRELIMINAR.pptx
SLIDEPRELIMINAR.pptx
 
3 engenharia de software
3   engenharia de software3   engenharia de software
3 engenharia de software
 
TesteDeSoftware_WorkshopSINFO2014.pdf
TesteDeSoftware_WorkshopSINFO2014.pdfTesteDeSoftware_WorkshopSINFO2014.pdf
TesteDeSoftware_WorkshopSINFO2014.pdf
 
Aula18_V&VTesteSoftware.pdf
Aula18_V&VTesteSoftware.pdfAula18_V&VTesteSoftware.pdf
Aula18_V&VTesteSoftware.pdf
 
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
 
Gerenciamento da Qualidade de Software 3.pptx
Gerenciamento da Qualidade de Software 3.pptxGerenciamento da Qualidade de Software 3.pptx
Gerenciamento da Qualidade de Software 3.pptx
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
 
Eng de testes
Eng de testesEng de testes
Eng de testes
 
Qualidade de software com Visual Studio ALM
Qualidade de software com Visual Studio ALMQualidade de software com Visual Studio ALM
Qualidade de software com Visual Studio ALM
 
Aula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptxAula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptx
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
 

Mais de Sérgio Souza Costa

Expressões aritméticas, relacionais e lógicas
Expressões aritméticas, relacionais e lógicasExpressões aritméticas, relacionais e lógicas
Expressões aritméticas, relacionais e lógicas
Sérgio Souza Costa
 
De algoritmos à programas de computador
De algoritmos à programas de computadorDe algoritmos à programas de computador
De algoritmos à programas de computador
Sérgio Souza Costa
 
Introdução ao pensamento computacional e aos algoritmos
Introdução ao pensamento computacional e aos algoritmosIntrodução ao pensamento computacional e aos algoritmos
Introdução ao pensamento computacional e aos algoritmos
Sérgio Souza Costa
 
Minicurso de introdução a banco de dados geográficos
Minicurso de introdução a banco de dados geográficosMinicurso de introdução a banco de dados geográficos
Minicurso de introdução a banco de dados geográficos
Sérgio Souza Costa
 
Modelagem de dados geográficos
Modelagem de dados geográficosModelagem de dados geográficos
Modelagem de dados geográficos
Sérgio Souza Costa
 
Banco de dados geográfico - Aula de Encerramento
Banco de dados geográfico - Aula de EncerramentoBanco de dados geográfico - Aula de Encerramento
Banco de dados geográfico - Aula de Encerramento
Sérgio Souza Costa
 
Banco de dados geográficos – Arquiteturas, banco de dados e modelagem
Banco de dados geográficos – Arquiteturas, banco de dados e modelagemBanco de dados geográficos – Arquiteturas, banco de dados e modelagem
Banco de dados geográficos – Arquiteturas, banco de dados e modelagem
Sérgio Souza Costa
 
Banco de dados geográficos - Aula de abertura
Banco de dados geográficos - Aula de aberturaBanco de dados geográficos - Aula de abertura
Banco de dados geográficos - Aula de abertura
Sérgio Souza Costa
 
Linguagem SQL e Extensões Espacias - Introdução
Linguagem SQL e Extensões Espacias - IntroduçãoLinguagem SQL e Extensões Espacias - Introdução
Linguagem SQL e Extensões Espacias - Introdução
Sérgio Souza Costa
 
Gödel’s incompleteness theorems
Gödel’s incompleteness theoremsGödel’s incompleteness theorems
Gödel’s incompleteness theorems
Sérgio Souza Costa
 
Turing e o problema da decisão
Turing e o problema da decisãoTuring e o problema da decisão
Turing e o problema da decisão
Sérgio Souza Costa
 
DBCells - an open and global multi-scale linked cells
DBCells - an open and global multi-scale linked cellsDBCells - an open and global multi-scale linked cells
DBCells - an open and global multi-scale linked cells
Sérgio Souza Costa
 
Conceitos básicos de orientação a objetos
Conceitos básicos de orientação a objetosConceitos básicos de orientação a objetos
Conceitos básicos de orientação a objetos
Sérgio Souza Costa
 
Polymorphism (Ad-hoc and Universal)
Polymorphism (Ad-hoc and Universal)Polymorphism (Ad-hoc and Universal)
Polymorphism (Ad-hoc and Universal)
Sérgio Souza Costa
 
Herança e Encapsulamento
Herança e EncapsulamentoHerança e Encapsulamento
Herança e Encapsulamento
Sérgio Souza Costa
 
Relações (composição e agregação)
Relações (composição e agregação)Relações (composição e agregação)
Relações (composição e agregação)
Sérgio Souza Costa
 
Abstract classes and interfaces
Abstract classes and interfacesAbstract classes and interfaces
Abstract classes and interfaces
Sérgio Souza Costa
 
Introdução ao Prolog
Introdução ao PrologIntrodução ao Prolog
Introdução ao Prolog
Sérgio Souza Costa
 
Heap - Python
Heap - PythonHeap - Python
Heap - Python
Sérgio Souza Costa
 
Paradigma lógico
Paradigma lógicoParadigma lógico
Paradigma lógico
Sérgio Souza Costa
 

Mais de Sérgio Souza Costa (20)

Expressões aritméticas, relacionais e lógicas
Expressões aritméticas, relacionais e lógicasExpressões aritméticas, relacionais e lógicas
Expressões aritméticas, relacionais e lógicas
 
De algoritmos à programas de computador
De algoritmos à programas de computadorDe algoritmos à programas de computador
De algoritmos à programas de computador
 
Introdução ao pensamento computacional e aos algoritmos
Introdução ao pensamento computacional e aos algoritmosIntrodução ao pensamento computacional e aos algoritmos
Introdução ao pensamento computacional e aos algoritmos
 
Minicurso de introdução a banco de dados geográficos
Minicurso de introdução a banco de dados geográficosMinicurso de introdução a banco de dados geográficos
Minicurso de introdução a banco de dados geográficos
 
Modelagem de dados geográficos
Modelagem de dados geográficosModelagem de dados geográficos
Modelagem de dados geográficos
 
Banco de dados geográfico - Aula de Encerramento
Banco de dados geográfico - Aula de EncerramentoBanco de dados geográfico - Aula de Encerramento
Banco de dados geográfico - Aula de Encerramento
 
Banco de dados geográficos – Arquiteturas, banco de dados e modelagem
Banco de dados geográficos – Arquiteturas, banco de dados e modelagemBanco de dados geográficos – Arquiteturas, banco de dados e modelagem
Banco de dados geográficos – Arquiteturas, banco de dados e modelagem
 
Banco de dados geográficos - Aula de abertura
Banco de dados geográficos - Aula de aberturaBanco de dados geográficos - Aula de abertura
Banco de dados geográficos - Aula de abertura
 
Linguagem SQL e Extensões Espacias - Introdução
Linguagem SQL e Extensões Espacias - IntroduçãoLinguagem SQL e Extensões Espacias - Introdução
Linguagem SQL e Extensões Espacias - Introdução
 
Gödel’s incompleteness theorems
Gödel’s incompleteness theoremsGödel’s incompleteness theorems
Gödel’s incompleteness theorems
 
Turing e o problema da decisão
Turing e o problema da decisãoTuring e o problema da decisão
Turing e o problema da decisão
 
DBCells - an open and global multi-scale linked cells
DBCells - an open and global multi-scale linked cellsDBCells - an open and global multi-scale linked cells
DBCells - an open and global multi-scale linked cells
 
Conceitos básicos de orientação a objetos
Conceitos básicos de orientação a objetosConceitos básicos de orientação a objetos
Conceitos básicos de orientação a objetos
 
Polymorphism (Ad-hoc and Universal)
Polymorphism (Ad-hoc and Universal)Polymorphism (Ad-hoc and Universal)
Polymorphism (Ad-hoc and Universal)
 
Herança e Encapsulamento
Herança e EncapsulamentoHerança e Encapsulamento
Herança e Encapsulamento
 
Relações (composição e agregação)
Relações (composição e agregação)Relações (composição e agregação)
Relações (composição e agregação)
 
Abstract classes and interfaces
Abstract classes and interfacesAbstract classes and interfaces
Abstract classes and interfaces
 
Introdução ao Prolog
Introdução ao PrologIntrodução ao Prolog
Introdução ao Prolog
 
Heap - Python
Heap - PythonHeap - Python
Heap - Python
 
Paradigma lógico
Paradigma lógicoParadigma lógico
Paradigma lógico
 

Teste de Software

  • 1. Testes de Software Prof: Sérgio Souza Costa
  • 2. Capítulo 12: Estratégias de teste de software
  • 3. Roteiro • Conceitos de teste de software • Atividades de teste de software • Níveis de teste de software
  • 4. Roteiro • Conceitos de teste de software • Atividades de teste de software • Níveis de teste de software
  • 5. Conceitos de testes de software
  • 6. Conceitos de teste de software Existe alguma diferença entre os termos defeito, falha e erro ? Ou são sinónimos ? Depurar é uma técnica de teste de software ?
  • 8. O fechamento não esperado de um programa.
  • 9. O fechamento não esperado de um programa. Durante um teste, ocorreu uma falha
  • 10. A falha pode ser entendida como consequencia.
  • 11. Mas qual é a causa ?
  • 13.
  • 14. Erro de acesso a memória
  • 16. Conceitos de testes de software • A Falha foi o fechamento não esperado do software. • O Erro foi um valor de endereço de memória inválido ou protegido. • O Defeito, estava na codificação. Por exemplo, o programador esqueceu de inicializar uma variável.
  • 17. Conceitos de testes de software • O padrão IEEE número 610.12-1990 – defeito (fault) – passo, processo ou definição de dados incorreto, como por exemplo, uma instrução ou comando incorreto, – erro (error) – diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado intermediário incorreto ou resultado inesperado na execução do programa constitui um erro; – falha (failure) – produção de uma saída incorreta com relação á especificação.
  • 18. Conceitos de testes de software Defeito Erro Falha Defeitos podem ocasionar a manifestação de erros. Erros podem gerar falhas. Falha é um comportamento inesperado que afeta diretamente o usuário.
  • 19. Conceitos de testes de software Uma falha pode ter sido causada por diversos erros e alguns erros Defeito Erro Falha podem nunca causar uma falha. Defeitos podem ocasionar a manifestação de erros. Erros podem gerar falhas. Falha é um comportamento inesperado que afeta diretamente o usuário.
  • 20. Conceitos de testes de software • Testes tem como objetivo causar falhas em um programa.
  • 21. Conceitos de testes de software • Testes tem como objetivo causar falhas em um programa. • Depois do teste, precisamos encontrar e corrigir defeitos, ou seja, depurar.
  • 22. Conceitos de testes de software • Testes tem como objetivo causar falhas em um programa. • Depois do teste, precisamos encontrar e corrigir defeitos, ou seja, depurar. Depurar não é testar
  • 23. Conceitos de testes de software Testes: Processo de execução de um programa com o objetivo de revelar a presença de falhas. Contribuem para aumentar a confiança de que o software desempenha as funções especificadas. Depuração: Consequência do teste. Após revelada a presença da falha, este deve ser encontrado e corrigido.
  • 24. Roteiro • Conceitos de teste de software • Atividades de teste de software • Níveis de teste de software
  • 25. Atividades de teste de software Teste é um elemento de um aspecto mais amplo, referido como verificação e validação (V&V).
  • 26. Atividades de teste de software Teste é um elemento de um aspecto mais amplo, referido como verificação e validação (V&V). Verificação e validação engloba muitas das atividades que são abrangidas para garantia de qualidade de software.
  • 27. Atividades de teste de software Verificação: Assegurar consistência, completitude e corretude do produto em cada fase e entre fases consecutivas do ciclo de vida do software. Estamos construindo corretamente o produto? Validação: Assegurar que o produto final corresponda aos requisitos do usuário. Estamos construindo o produto certo? Teste: Examina o comportamento do produto por meio de sua execução.
  • 28. Atividades de teste de software Verificação e validação estão no nível D do mpsBr.
  • 29. Atividades de teste de software “Testing can only show the presence of errors, not their absence” (Dijkstra et al., 1972). Testes podem somente mostrar a presença de erros, não a sua ausência.
  • 30. Atividades de teste de software Objetivo do teste é causar uma falha, então a inexistência de falha pode ser explicado por: • Software é de alta qualidade? • Os testes foram de baixa qualidade ?
  • 31. Atividades de teste de software Testes nunca Objetivo do teste é causar uma falha, então a vez que terminam, toda o usuário utiliza um inexistência de falha pode ser explicado por: programa, ele esta testando-o. • Software é de alta qualidade? • Os testes foram de baixa qualidade ?
  • 32. Atividades de teste de software Testes de software Se uma falha não é Objetivo do teste é causar uma falha, então atoda vez nunca termina, identificadaopela equipe um que usuário utiliza inexistência de falha pode ser explicado por: de programa, ele esta desenvolvimento, será testando-o. identificada pelo • Software é de alta qualidade? usuário. • Os testes foram de baixa qualidade ?
  • 33. Atividades de teste de software • Para garantir a qualidade dos testes, estes devem ser feitos de forma sistemática, que inclui: 1. Planejamento de testes, 2. Projeto de casos de teste, 3. Execução e avaliação dos resultados dos testes.
  • 34. Planejamento de testes • Planejar é distribuir racionalmente no tempo os recursos disponíveis para realizar alguma atividade. • No caso de testes será gerado o plano de teste: – Definir o método, – Recursos necessários – Cronograma de atividades – Pessoal necessário – O que será testado – O que não será testado – Responsáveis
  • 35. Projeto de testes • O projeto de casos de teste pode ser tão difícil quanto o projeto do próprio produto a ser testado. • Poucos desenvolvedores gostam de teste e, menos ainda, do projeto de casos de teste • Será escolhido um grupo específico de características a serem testadas. Descrevendo detalhadamente os métodos e testes que deverão ser executados. • O resultado será o documento de caso de testes e o procedimento de teste.
  • 36. Casos de testes • Especificação de uma entrada para o programa e a correspondente saída esperada – Entrada: conjunto de dados necessários para uma execução do programa – Saída esperada: resultado de uma execução do programa • Um bom caso de teste tem alta probabilidade de revelar uma falha ainda não descoberta.
  • 37. Execução de teste • Os casos de testes serão executados. • Todo atividade de teste deve ser registrada, identificando: – Hora do teste – Procedimento – Pessoal envolvido – Resultados obtidos – Condições ambientais – Eventos não esperando (quando ocorrerem)
  • 38. Roteiro • Conceitos de teste de software • Atividades de teste de software • Níveis de teste de software
  • 39. Quais as origens dos defeitos em software ? Onde e quando eles ocorrem ?
  • 40. Defeitos no processo de desenvolvimento Como o software é um produto lógico, defeitos são de origem humana.
  • 41. Defeitos no processo de desenvolvimento Um software falha quando ele não esta de acordo com o esperado pelo usuário. Lembrando que o esperado pelo usuário não é necessariamente o que foi especificado de modo que a falha de um sistema não esta relacionada apenas a defeitos na codificação e ou projeto. Os defeitos normalmente são introduzidos na transformação de informações entre as diferentes fases do ciclo de desenvolvimento de um software. Dos requisitos a codificação.
  • 42. Defeitos no processo de desenvolvimento As diversas transformações de um requisito de software. Descrição textual Casos de uso Diagramas de classe, iteração Defeitos tendem a aparecer e ou a Código propagar durante as transformações
  • 43. Defeitos no processo de desenvolvimento Muitos encontram- se em partes do As diversas transformações de código raramente executadas um requisito de software. Descrição textual Casos de uso Diagramas de classe, iteração Defeitos tendem a aparecer e ou a Código propagar durante as transformações
  • 44. Níveis de teste de software • Os testes devem ser executados em diferentes níveis, visando avaliar o software em diferentes perspectivas de acordo com o produto gerado em cada fase do ciclo de vida de desenvolvimento de um software (Pressman, ). – Testes de unidade: as menores unidades funcionam corretamente? – Testes de integração: quando integradas elas continuam a produzir o resultado esperado ? – Testes de validação: (ou aceitação) o programa produz o resultado esperado pelo usuário? – Testes de sistema: o programa funciona como esperado no seu ambiente como todo ?
  • 45. Níveis de teste de software Testes de unidade Código
  • 46. Níveis de teste de software Testes de integaçao Testes de unidade Código Projeto
  • 47. Níveis de teste de software Testes de validação Testes de integaçao Testes de unidade Código Projeto Requisitos
  • 48. Níveis de teste de software Teste de sistema Testes de validação Testes de integaçao Testes de unidade Código Projeto Requisitos Engenharia de sistemas
  • 49. Níveis de teste de software Teste de Regressão não corresponde a um nível de teste, mas é uma estratégia importante para redução de “efeitos colaterais”. Consiste em se aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. Pode ser aplicado em qualquer nível de teste.
  • 50. Testes de unidade • Tem como proposito testar a menor unidade do programa. • Usa-se a descrição do projeto no nível da unidade como guia para os testes. • Os erros estarão nos limites destas unidades. • Pode ser conduzido em paralelo para diversas unidades.
  • 51. Testes de unidade Unidade Interface Estruturas de dados Condições limites Caminhos independentes Caminhos de manipulação de erros Casos de teste
  • 52. Testes de unidade • Interface, é testada para garantir que a informação flui adequadamente para dentro e para fora da unidade do programa. • Estrutura de dados, é examinada para garantir que os dados armazenados temporariamente mantenham sua integridade durante todos os passos do programa. • As condições-limites são testadas para garantir que a unidade opere adequadamente nos limiares. • Todos os caminhos independentes (básicos) são exercitados para garantir que que todos os comandos tenham sido executados • Todos os caminhos de manipulação de erros são testados.
  • 53. Testes de unidade • Interface, é testada para garantir que a informação flui adequadamente para dentro e para fora da unidade do programa. • Estrutura de dados, é examinada para garantir que os dados armazenados temporariamente mantenham sua integridade durante todos os passos do programa. • As condições-limites são testadas para garantir que a unidade opere adequadamente nos limiares. • Todos os caminhos independentes (básicos) são exercitados para garantir que que todos os comandos tenham sido executados • Todos os caminhos de manipulação de erros são testados.
  • 54. Testes de unidade: Interface • Testes de fluxo de dados entre as interfaces são necessários antes de qualquer outro teste. • Se os dados não entram e nem saem adequadamente, todo os testes são discutíveis.
  • 55. Testes de unidade: ED • As estruturas de dados (ED) locais devem ser exercitadas • O impacto local nos dados globais devem ser verificados (se possível) durante o teste de unidade.
  • 56. Teste de unidade: teste de caminho • Casos de testes devem ser projetados para descobrir erros devidos a cálculos errados, comparações incorretas ou fluxo de controle inadequado. • Exemplos: – Inicialização incorreta, representação incorreta de uma expressão, erros de operadores ou precedência, variáveis de ciclo inadequadamente modificada e etc
  • 57. Teste de unidade: limites • Teste nos limites é uma das mais importantes tarefas do teste de unidade. • O software frequentemente falha nos limites: – N-esimo elemento de um vetor de dimensão N é processado, a I-esima repetição de um ciclo com I passagens, valor máximo ou mínimo é encontrado e etc.
  • 58. Teste de unidade: exceção • Erros potenciais no tratamento de erro (ou exceção): 1. Descrição de erro ininteligível 2. Erro mencionado não corresponde ao erro encontrado 3. A condição de erro provoca a intervenção do sistema antes da manipulação de erro 4. O processamento da condição de exceção de erro esta incorreto. 5. A descrição de erro não fornece informação suficiente para encontrar o defeito
  • 59. Testes de unidade: procedimento • Normalmente considerado um apêndice ao passo de codificação. • O projeto de teste pode ser realizado antes que o código seja iniciado (abordagem ágil) • Cada cada caso de teste deve ser acoplado a um conjunto de resultados esperados.
  • 60. São capazes de identificar um desafio prático com relação aos testes de unidade?
  • 61. Testes de unidade: procedimento • Uma unidade não é um programa isolado, o software para um pseudocontrolador (driver) e ou pseudocontrolado (stub) precisa ser desenvolvido para cada caso de teste. – Em muitos casos o pseudocontrolador será apenas um programa principal, que aceita dados do caso de teste e passa para unidade. – Pseudocontrolado substitui unidades subordinados a unidade a ser testada.
  • 62. Testes de unidade: procedimento Pseudocontroladores e • Uma unidade não é um programa isolado, são pseudocontrolados o despesas indiretas. software para um pseudocontrolador (driver) e ou pseudocontrolado (stub) precisa ser desenvolvido para cada caso de teste. – Em muitos casos o pseudocontrolador será apenas um programa principal, que aceita dados do caso de teste e passa para unidade. – Pseudocontrolado substitui unidades subordinados a unidade a ser testada.
  • 63. Testes de unidade: procedimento Pseudocontroladores e • Uma unidade não é um programa isolado, são pseudocontrolados o Em alguns casos pode despesas indiretas. software para um pseudocontrolador (driver) não valer a pena e ou pseudocontroladodesenvolvê-los, tendo (stub) precisa ser desenvolvido para cadaque adiar osteste. caso de testes. – Em muitos casos o pseudocontrolador será apenas um programa principal, que aceita dados do caso de teste e passa para unidade. – Pseudocontrolado substitui unidades subordinados a unidade a ser testada.
  • 64. Como a alta coesão de uma unidade pode afetar o teste de unidade?
  • 65. Testes de unidade: procedimento • Testes de unidades são simplificados em componentes com alta coesão. • Quando uma única função é implementada o número de casos de testes é reduzido e os erros podem ser mais facilmente previstos e descobertos.
  • 66. Testes de unidade: procedimento • Testes de unidades são simplificados em Por isso o teste de componentes com altaprogramas escritos em coesão.funcionais linguagens • Quando uma única função Haskell tendem a ser o como é implementada número de casos de testesfáceis. A disciplina os mais é reduzido e destas linguagens torna as erros podem ser mais facilmente previstos e funções altamente coesas. descobertos.
  • 67. Testes de unidade • Os testes de unidade em linguagens funcionais, como Haskell, focam nas funções. • Em linguagens procedurais como C, os testes de unidades são em procedimentos.
  • 68. Testes de unidades Em linguagens orientadas a objetos, os testes de unidades podem focar apenas nos métodos isoladamente ?
  • 69. Testes de unidade em OO • Considerem uma hierarquia de classe, na qual uma operação X é definida para uma superclasse e herdada por várias subclasses. • A operação X será aplicada sobre diferentes contextos. • Precisamos testar a operação X como parte de uma classe.
  • 70. Se minhas unidades funcionam como o esperado, não significa que meu software irá funcionar como o esperado ?
  • 71. Testes de integração • Infelizmente, software é um sistema complexo. Defeitos de projetos podem: – Perder dados entre as interfaces (ex: dados incompátiveis) – Efeito imprevisto ou adverso sobre o outro (ex: variáveis globais) – Subfunções quando integradas podem não produzir o resultado esperado pela função principal. – etc
  • 72. Testes de integração • Infelizmente, software é um sistema complexo. DefeitosAde projetosdas imutabilidade podem: variáveis em linguagem – Perder dados entrefuncional tende a evitar as interfaces (ex: dados incompátiveis) algumas das falhas relacionadas a integração. – Efeito imprevisto ou adverso sobre o outro (ex: variáveis globais) – Subfunções quando integradas podem não produzir a função principal. – etc
  • 73. Testes de integração • Técnica sistemática para construir a arquitetura do software e ao mesmo tempo, conduz testes para descobrir falhas associadas a interface. • Abordagens: – a) Não incremental e b) incremental
  • 74. Testes de integração: não incremental • A integração não incremental, ou seja, a abordagem big-bang. – Todos os componentes são integrados e o sistema é testado. – Não existe uma abordagem sistemática para integração • Abordagem caótica, um conjunto de falhas é identificada e a correção é difícil, pois o isolamento das causas é complicado.
  • 75. Testes de integração: não incremental • A integração não incremental, ou seja, a Para os que já fizeram abordagem big-bang. disciplina de programação comigo. – Todos os componentes sãofez lembrar de algoo sistema Isto integrados e é testado. que eu sempre falo para vocês ? – Não existe uma abordagem sistemática para integração • Abordagem caótica, um conjunto de falhas é identificada e a correção é difícil, pois o isolamento das causas é complicado.
  • 76. Testes de integração: incremental • Antítese da abordagem big-bang. O programa é construído e testado em pequenos incrementos, em que os erros são mais fáceis de isolar e corrigir: – Integração descendente (top-down), as unidades são integradas movendo descendentemente pela hierarquia, começa pela unidade principal(programa principal) e dela as unidades subordinadas. – Integração ascendente (bottom-up), inicia o teste com as unidades atômicas (níveis mais baixos do programa) e são integrados de baixo para cima.
  • 77. Integração top-down Primeiro-em-profundidade vs Primeiro-em-largura M1 M2 M3 M4 M5 M6 M7 M8
  • 78. Integração top-down Primeiro-em-profundidade vs Primeiro-em-largura M1 M2 M3 M4 Lembraram de busca em grafo ? M5 M6 M7 M8
  • 79. Integração top-down 1. O modulo principal é usado como pseudocontrolador do teste, e pseudocontrolados sao substituídos pelas unidades subordinadas. – Primeiro-em-largura ou primeiro-em-profundidade. 2. Testes sao conduzidos a medida que cada componente é integrado 3. Ao término de cada conjunto de testes, outro pseudocontrolado é substituído pela unidade real. 4. Testes de regressão podem ser conduzidos para garantir que novos erros (efeitos colaterais) não tenham sido introduzidos.
  • 80. Qual problema com relação a integração top-down ?
  • 81. Integração top-down • O processamento de níveis baixos da hierarquia são necessários para testar os níveis superiores. Soluções: 1. Adiar muitos testes 2. Desenvolver pseudocontrolados 3. Integrar o software de baixo para cima.
  • 82. Integração bottom-up • Os componentes são integrados de baixo para cima, as unidades subordinadas estão sempre disponíveis. • Necessidades de pseudocontrolados é eliminada. • Pseudocontroladores são necessários.
  • 83. Integração bottom-up 1. Componentes de baixo nível são combinados em agregados (clusters, algumas vezes chamados de construções) que realizam uma subfunção especifica. 2. Um pseudocontrolador é escrito para coordenar a entrada e a saída dos casos de teste 3. O agregado e testado. 4. Pseudocontroladores são removidos e agregados são combinados movendo-se para cima da estrutura do programa.
  • 84. Integraçao bottom-up Uc Pseudocontroladores Ua Ub P1 P2 P3 Agregado 3 Agregado 1 Agregado 2
  • 85. E os testes de integração, o uso de orientação a objeto tem algum impacto sobre as abordagens descendentes (top-down) e ascendente (bottom-up) ?
  • 86. Testes de integração em OO • Em OO os objetos se relacionam e colaboram em tempo de execução de modo não obvio. • A abordagem convencional não é efetiva. • Duas estratégias: – Testes baseados na execução, integra um conjunto de classes necessárias para responde uma entrada ou um evento do sistema. – Testes baseado no uso uso, testam as classes independentes e depois as dependentes.
  • 87. Testes de integração em OO • Em OO os objetos se relacionam e colaboram em tempo de execução de modo não obvio. • A abordagem convencional que oé efetiva. Observem não uso de um paradigma tem • Duas estratégias: impacto em todo o processo de – Testes baseados na execução, integra um conjunto de desenvolvimento. classes necessárias para responde uma entrada ou um evento do sistema. – Testes baseado no uso uso, testam as classes independentes e depois as dependentes.
  • 88. Testes de validação • Começa no fim do teste de integração, quando o software está completamente montado. • Na validação não existe distinção de paradigmas. • O teste focaliza ações visíveis ao usuário e saídas do sistema reconhecida pelo usuário.
  • 89. Testes de validação • Uma validação se torna bem sucedida, quando o software funciona de modo que pode ser razoavelmente esperado pelo usuário (Pressman).
  • 90. Testes de validação • Uma validação se torna bem sucedida, quando o software funciona de modo que pode ser razoavelmente esperado pelo usuário (Pressman). • Expectativas razoáveis são definidas nas especificações de requisitos de software.
  • 91. Testes de validação • Uma validação se torna bem sucedida, quando o software funciona de Lembrem-se, requisitos modo que podesempre mudam, e ser razoavelmente esperado pelo usuário (Pressman). capturam a dificilmente real necessidade do • Expectativas razoáveis são definidas nas usuário. especificações de requisitos de software.
  • 92. Testes de validação • Como os requisitos mudam, abordagens modernas (incluindo os métodos ágeis) optam por entregar incrementos validáveis ao usuário com maior frequência. • Isso permite encontrar desvios nas especificações mais cedo durante o ciclo do software.
  • 93. Testes de validação • Como os requisitos mudam, abordagens modernas (incluindo os métodos ágeis) optam e entregar Processos iterativos por incrementos validáveis ao usuárioé incrementais não com maior frequência. exclusividade dos métodos ágeis. Eles • Isso permite encontrar desvios nas de existem bem antes especificações mais cedo durantemuitos dos métodos o ciclo do software. ágeis surgirem.
  • 94. Testes de validação • Testes com os usuários: teste alfa e beta: • Teste alfa, o usuário testa o software na presença do desenvolvedor. Os desenvolvedores podem anotar as falhas. • Testes beta, o usuário testa o software em seu ambiente real. Neste caso os clientes que registram as falhas de software
  • 95. Testes de sistema • O software é apenas um elemento de um sistema maior baseado em computador. – Hardware, pessoas e informação. • Testes de sistema é na verdade uma série de diferentes testes, cuja finalidade principal é exercitar por completo o sistema baseado em computador. – Testes de recuperação, testes de segurança, testes de estresse e testes de desempenho.
  • 96. Testes de sistema: Testes de recuperação • O sistema é tolerante a falha ? Falhas no sistema não podem causar interrupção da função global do sistema. • Teste de recuperação força um software falhar e verifica: – A recuperação é automática? – A integridade dos dados são mantidas? – O tempo de recuperação (e ou reparo) está em tempo aceitável.
  • 97. Testes de sistema: teste de segurança • Testes de segurança verifica se os mecanismos de proteção incorporados a um sistema vão de fato protegê-lo de invasão imprópria. • O testador desempenha o papel do indíviduo que deseja invadir o sistema. Vale tudo! – Tentar obter ou descobrir senhas – Usar software especialista para intrusão – Causar falhas para tentar invadi-lo durante a recuperação. – etc
  • 98. Testes de sistema: teste de segurança • Testes de segurança verifica se os mecanismos de proteção incorporados a um sistema vão de fato protegê-lo de invasão imprópria. O bom teste vai acabar invadindo o sistema. O bom projeto vai tornar • O testador desempenha o papel do indívido que o custo maior que o deseja invadir o sistema. informação a valor da Vale tudo! – Tentar obter ou descobrir senhas ser obtida. – Usar software especialista para intrusão – Causar falhas para tentar invadi-lo durante a recuperação. – etc
  • 99. Teste de estresse • Testes de estresse executa um sistema de tal forma que a demanda de recursos em quantidade, frequência ou volume são anormais. • Por exemplo: – a) Velocidade de entrada de dados pode ser aumentada, b) casos de teste que exigem o máximo de memória ou outros recursos, c) busca excessivas de dados em disco ...
  • 100. Teste de estresse • Testes de estresse executa um sistema de tal forma que a demanda de recursos em O testador irá a todo quantidade, frequência ou volume são anormais. custo tentar quebrar o sistema. • Por exemplo: – a) Velocidade de entrada de dados pode ser aumentada, b) casos de teste que exigem o máximo de memória ou outros recursos, c) busca excessivas em dados em disco ...
  • 101. Teste de desempenho • O teste de desempenho é projetado para testar o desempenho de um sistema integrado. • O teste ocorre ao longo de todos os passos do processo de teste. • Mesmo no nível de unidade pode ser avaliado a medida que testes são conduzidos. – O verdadeiro desempenho de um sistema não pode ser avaliado antes que todos os sistemas estejam plenamente integrados. • Testes de desempenho são frequentemente acoplados a testes de estresse.
  • 102. Pontos chaves • Defeitos podem ocasionar a manifestação de erros. • Erros podem gerar falhas. • Falha é um comportamento inesperado que afeta diretamente o usuário • Testes tem como objetivo causar falhas em um programa. • Depuracao tem como objetivo encontrar um defeito de codificação
  • 103. Pontos chaves • Teste é uma atividade relacionada ao processo de verificação e validação, que por sua vez faz parte do processo de garantia de qualidade de software. • Para ascender ao nivel D do mpsBr, é necessário haver um processo sistemático de testes de software. • Defeitos de software podem ocorrer em qualquer fase, da especificação a codificação.
  • 104. Pontos chaves • Os níveis de testes são: testes de unidade, integração, validação e de sistema. • Os testes de unidade testam a menor unidade do programa. • Os testes de integração testam a integração destas unidades. • Testes de validação testam se o programa se comporta como o esperado pelo usuário. • Testes de sistema testa o sistema como todo, incluindo hardware, pessoas e informação.
  • 105. Pontos chaves • O uso de um paradigma de desenvolvimento afeta o procedimento de testes. • Testes são muito importantes para garantir a qualidade de um software, porém tem um alto custo. • Testes realizados de modo informal, tendem ser apenas um custo extra, sem garantia de melhoria na qualidade. – Testes devem ser realizados de maneira sistemática
  • 106. Próxima aula Próxima exercitaremos a escrita de casos de uso com o projeto que estamos trabalhando durante todo o curso.