Engenharia de Testes

4,593 views
4,472 views

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,593
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
161
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Engenharia de Testes

  1. 1. INTRODUÇÃO A TESTE DE SOFTWARE Adriana C. Nascimento Danilo Dias Luma da R. Seixas Yuko Mitsuya
  2. 2. TESTE CONCEITO DE TESTE: “ Exame ou prova para avaliar uma capacidade ou aptidão de alguém, ou para determinar a qualidade, natureza ou comportamento de algo. ” (Fonte: Minidicionário da língua Portuguesa)
  3. 3. TESTE DE SOFTWARE CONCEITO: “ É o processo de execução de um produto para determinar se ele atingiu suas especificações e funcionou corretamente no ambiente para o qual foi projetado ” . “ É uma das fases do processo de engenharia de software que visa atingir um nível superior da qualidade de software. ”
  4. 4. TESTE DE SOFTWARE É parte de um tema mais amplo chamado Verificação e Validação (V&V), onde: Verificação - refere-se ao conjunto de atividades que garante que o software implementa corretamente uma função específica, e; Validação - refere-se ao conjunto de atividades que garante que o software que foi construído atende às exigências do cliente.
  5. 5. TESTE DE SOFTWARE Logo, “ Testar um software significa verificar através de uma execução controlada se o seu comportamento corre de acordo com o especificado. ”
  6. 6. TESTE DE SOFTWARE OBJETIVO: “ Revelar o número máximo de falhas dispondo do mínimo de esforço, ou seja, mostrar aos que desenvolvem se os resultados estão ou não de acordo com os padrões estabelecidos ” .
  7. 7. TESTE DE SOFTWARE IMPORTÂNCIA: Economia: Quanto mais cedo um defeito for encontrado, mais barato é o custo da sua correção; Qualidade: Devem ser encarados como investimento em qualidade.
  8. 8. TESTE DE SOFTWARE DEFEITO, ERRO, FALHAS
  9. 9. TESTE DE SOFTWARE Elementos Essenciais <ul><li>Caso de Teste: </li></ul><ul><ul><li>Condição particular a ser testada; </li></ul></ul><ul><ul><li>Composta por valores de entrada, restrições, e resultado ou comportamento esperado. </li></ul></ul>
  10. 10. TESTE DE SOFTWARE Elementos Essenciais <ul><li>Procedimento de Teste: </li></ul><ul><ul><li>Descrição dos passos necessários para executar um caso de teste, ou grupo de casos; </li></ul></ul>
  11. 11. TESTE DE SOFTWARE Elementos Essenciais <ul><li>Critério de Teste: </li></ul><ul><ul><li>Selecionar e avaliar os casos de teste; </li></ul></ul><ul><ul><li>Estabelecer um nível elevado de confiança na correção do produto. </li></ul></ul>
  12. 12. TESTE DE SOFTWARE Critérios de Teste <ul><li>Cobertura de Testes: </li></ul><ul><ul><li>Identificação de partes do programa que devem ser executadas para garantir a qualidade do software; </li></ul></ul><ul><ul><li>Indicar quando o mesmo foi suficientemente testado. </li></ul></ul>
  13. 13. TESTE DE SOFTWARE Critérios de Teste <ul><li>Adequação de Casos de Teste: </li></ul><ul><ul><li>Verificar se um conjunto de casos de teste satisfaz aos requisitos de teste estabelecidos pelo critério; </li></ul></ul>
  14. 14. TESTE DE SOFTWARE Critérios de Teste <ul><li>Geração de Casos de Teste: </li></ul><ul><ul><li>Quando o critério define regras e diretrizes para geração dos casos de teste de um produto que esteja de acordo com o critério de adequação definido. </li></ul></ul>
  15. 15. TIPOS DE TESTE <ul><ul><li>Os tipos de teste normalmente são definidos em função das características ou dimensões da qualidade que serão avaliadas no software. </li></ul></ul><ul><li>  </li></ul><ul><ul><li>&quot;A totalidade de características de um produto de software  que lhe confere a capacidade de satisfazer necessidades explícitas e implícitas&quot;.(NBR 13596) </li></ul></ul>
  16. 16. TIPOS DE TESTE <ul><ul><li>O que são necessidades explícitas e implícitas? </li></ul></ul><ul><li>  </li></ul><ul><ul><li>  As explícitas são condições e objetivos propostos por aqueles que produzem o software.  </li></ul></ul><ul><li>  </li></ul><ul><ul><li>As implícitas são necessidades subjetivas dos usuários, devem permitir atingir metas como: efetividade, produtividade, segurança e etc. </li></ul></ul>
  17. 17. TIPOS DE TESTE A ISO/IEC 9126 (NBR 13596) fornece um modelo que define 6 amplas categorias de características de qualidade, por sua vez, sub-divididas em sub-características. Característica Sub-características Funcionalidade: O conjunto de funções satisfaz as necessidades explicitas e implícitas para a finalidade a que se destina o produto? Adequação, acurácia, interoperabilidade, segurança de acesso e conformidade. Confiabilidade: O desempenho se mantém ao longo do tempo e em condições estabelecidas? Maturidade, tolerância a falhas e recuperabilidade. Usabilidade: É fácil utilizar o software? Inteligibilidade, apreensibilidade e operacionalidade. Eficiência: Os recursos e os tempos utilizados são compatíveis com o nível de desempenho requerido para o produto? Comportamento em relação ao tempo e comportamento em relação aos recursos Manutenibilidade: Há facilidade para correções, atualizações e alterações? Analisabilidade, modificabilidade, estabilidade e testabilidade. Portabilidade: É possível utilizar o produto em diversas plataformas com pequeno esforço de adaptação? Adaptabilidade, capacidade para ser instalado, capacidade para substituir e conformidade.
  18. 18. TIPOS DE TESTE A escolha do tipo de teste dependerá do grau de importância de cada uma das características de qualidade que serão avaliadas no software. Os tipos de testes mais comuns segundo  o Guide to the CSTE Common Body of Knowledge do QAI são: Tipos de testes Descrição Teste de Estresse Avalia o desempenho do sistema com um volume de acesso/trasações acima da média esperada em condições extremas de uso. Teste de Execução Avalia se o sistema atende os requisitos de performance (proficiência) com um volume de acesso/trasanções dentro do esperado. Teste Contigência Avalia se o sistema retorna a um status operacioal após uma falha. Teste de Operação Avalia se o sistema (aplicação, pessoal, procedimentos e manuais) pode ser executado corretamente em ambiente de pré-produção. Teste de Conformidade Avalia se o sistema foi desenvolvido em consônancia com os padões e metodologia estabelecidos no projeto. Teste de Segurança Avalia se o sistema foi desenvolvido em consonância com os padrões de segurança da organização. Teste de Regressão Avalia por meio do ré-teste se uma funcionalidade que estava funcionando ainda funciona após uma modificação no sistema. Teste de Integração Avalia se a interconexão entre as aplicações funciona corretamente.
  19. 19. PROCESSO ESTRUTURA DE TESTE DE SOFTWARE  <ul><li>  </li></ul><ul><li>  </li></ul><ul><ul><li>Um processo estruturado de software tem a finalidade de formalizar as fases, atividades, papéis, artefatos e responsabilidades necessárias para o planejamento e a execução dos testes sistematicamente. </li></ul></ul>
  20. 20. PROCESSO ESTRUTURA DE TESTE DE SOFTWARE  <ul><li>            </li></ul><ul><li>  </li></ul><ul><li>                O ciclo de vida do TMAP é dividido em sete fases distintas, como podemos                 observar a seguir: </li></ul><ul><li>  </li></ul><ul><ul><li>Planejamento: Nesta fase é realizada o planejamento e a definição geral da estratégia e planos de testes. </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Controle: Nesta fase são realizados o controle e a monitoração das atividades planejadas. </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Configuração e manutenção da infra-estrutura: Nesta fase é preparada e mantida a infra-estrutura(software e hardware) necessária para a plena realização dos testes. </li></ul></ul>
  21. 21. PROCESSO ESTRUTURA DE TESTE DE SOFTWARE  <ul><ul><li>Preparação: É realizado o refinamento da estratégia de testes e plano de testes criados na fase de planejamento. </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Especificação: Nesta fase é realizada a especificação dos casos de testes e demaisdocumentos. </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Execução: É realizada a execução dos testes, reporte do progresso e indicadores de qualidade. </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Conclusão: Fase do processo de testes é avaliada afim de promover as melhorias para os próximos projetos. </li></ul></ul>
  22. 22. Níveis de Teste <ul><ul><li>As atividades de teste são normalmente divididas em níveis. </li></ul></ul><ul><ul><li>Define a fase do processo de desenvolvimento de software na qual os testes serão realizados. </li></ul></ul><ul><ul><ul><li>Teste de unidade </li></ul></ul></ul><ul><ul><ul><li>Teste de integração </li></ul></ul></ul><ul><ul><ul><li>Teste de sistema </li></ul></ul></ul><ul><ul><ul><li>Teste de aceitação </li></ul></ul></ul>9/29/2010
  23. 23. Níveis de Teste Teste de Unidade 9/29/2010 <ul><ul><li>Objetiva explorar a menor unidade do projeto, procurando provocar falhas ocasionadas por defeito de lógica e de implementação em cada módulo, separadamente. </li></ul></ul><ul><ul><li>Universo alvo são pequenos trechos de código. </li></ul></ul>
  24. 24. Níveis de Teste Teste de Integração 9/29/2010 <ul><ul><li>Visa provocar falhas associadas às interfaces entre os módulos quando esses são integrados para construir a estrutura do software que foi estabelecida na fase de projeto. </li></ul></ul><ul><ul><li>Integração entre os componentes do sistema (classes, módulos, sub-sistemas, etc). </li></ul></ul>
  25. 25. Níveis de Teste Teste de Sistema 9/29/2010 <ul><ul><li>Avalia o software em busca de falhas por meio da utilização do mesmo, como se fosse um usuário final. </li></ul></ul><ul><ul><li>Verificação se o produto satisfaz os seus requisitos. </li></ul></ul>
  26. 26. Níveis de Teste Teste de Aceitação 9/29/2010 <ul><ul><li>É feita uma simulação, por um grupo restrito de usuários, para a realização de operações de rotina do sistema de modo a verificar se o seu comportamento está de acordo com o solicitado. </li></ul></ul><ul><ul><li>Verifica se o sistema satisfaz os requisitos (funcionais e não funcionais), sob o ponto de vista do usuário final. </li></ul></ul>
  27. 27. Modelo V 9/29/2010 <ul><ul><li>Planejamento e projeto devem ocorrer de cima para baixo. </li></ul></ul>
  28. 28. Técnica de Teste de Software 9/29/2010 <ul><ul><li>Objetiva encontrar falhas no software. </li></ul></ul><ul><ul><li>São classificadas de acordo com a origem das informações utilizadas para estabelecer os requisitos de teste. </li></ul></ul><ul><ul><li>Pode-se estabelecer uma estratégia de teste que contenple as vantagens e os aspectos complementares dessas técnicas. </li></ul></ul><ul><ul><ul><li>Técnica Estrutural </li></ul></ul></ul><ul><ul><ul><li>Técnica Funcional </li></ul></ul></ul>
  29. 29. Técnica Estrutural 9/29/2010 <ul><ul><li>Também chamado teste caixa-branca </li></ul></ul><ul><ul><li>Técnica de teste que avalia o comportamento interno do componente de software. </li></ul></ul><ul><ul><li>Trabalha diretamente sobre o código fonte do componente de software e avalia: </li></ul></ul><ul><ul><ul><li>Teste condição; </li></ul></ul></ul><ul><ul><ul><li>Teste de fluxo de dados; </li></ul></ul></ul><ul><ul><ul><li>Teste de ciclos; e </li></ul></ul></ul><ul><ul><ul><li>Teste de caminhos lógicos. </li></ul></ul></ul>
  30. 30. Técnica Estrutural 9/29/2010 <ul><ul><li>Os aspectos válidos dependem: </li></ul></ul><ul><ul><ul><li>Da complexidade </li></ul></ul></ul><ul><ul><ul><li>Da tecnologia </li></ul></ul></ul><ul><ul><li>É desenvolvido analisando-se o código fonte e elaborando-se casos de teste que cubram todas as possibilidades do componente de software. </li></ul></ul><ul><ul><li>Todas as variações de estruturas de condição são testadas. </li></ul></ul>
  31. 31. Técnica Estrutural 9/29/2010 <ul><ul><li>Técnica recomendada para os níveis de Teste de Unidade e Teste de Integração. </li></ul></ul><ul><ul><li>A responsabilidade principal fica a cargo dos desenvolvedores do sistema. </li></ul></ul><ul><ul><li>Auxilia na redução de problemas existentes nas pequenas funções ou unidades que compõem o software. </li></ul></ul>
  32. 32. Técnica Funcional 9/29/2010 <ul><ul><li>Também chamada de teste caixa-preta. </li></ul></ul><ul><ul><li>NÃO considera o comportamento interno do software. </li></ul></ul><ul><ul><li>Os dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado. </li></ul></ul>
  33. 33. Técnica Funcional 9/29/2010 <ul><ul><li>O componete de software a ser testado pode ser um método, uma função interna, um programa, um componete, um conjunto de componentes ou mesmo uma funcionalidade. </li></ul></ul><ul><ul><li>É aplicável a todos os níveis de teste. </li></ul></ul>
  34. 34. Critérios de teste Particionamento de classes de equivalência 9/29/2010 <ul><ul><li>Divide o domínio da entrada de um programa em classes de equivalência. A partir das quais os casos de teste são derivados </li></ul></ul><ul><ul><li>Minimiza o número de casos de teste de cada classe, pois em princípio todos os elementos de uma classe devem se comportar de maneira equivalente. </li></ul></ul><ul><ul><li>Classe equivalente representa um conjunto de estados válidos e inválidos para uma condição de entrada. </li></ul></ul>
  35. 35. Critérios de teste Análise de Valor Limite 9/29/2010 <ul><ul><li>Erros tendem a ocorrer nos limites do domínio de entrada ao invés do centro. </li></ul></ul><ul><ul><li>Explorar os limites dos valores de cada classe de equivalência para preparar os casos de teste. </li></ul></ul>
  36. 36. Critérios de teste Grafo de Causa-efeito 9/29/2010 <ul><ul><li>Verifica o efeito combinado de dados de entrada. </li></ul></ul><ul><ul><li>As causas (condições de entrada) e os efeitos (ações) são identificados e combinados em um grafo. </li></ul></ul>
  37. 37. Critérios de teste Grafo de Causa-efeito 9/29/2010 <ul><ul><li>Esse critério é baseado em quatro passos: </li></ul></ul><ul><ul><ul><li>Para cada módulo de causa e efeito são relacionados, atribuindo-se um identificador para cada um. </li></ul></ul></ul><ul><ul><ul><li>O grafo de causa-efeito é elaborado. </li></ul></ul></ul><ul><ul><ul><li>Transforma-se o grafo de causa-efeito numa tabela de decisão. </li></ul></ul></ul><ul><ul><ul><li>As regras da tabela são convertidas em casos de teste. </li></ul></ul></ul>

×