Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Engenharia de Testes

5,079 views

Published on

  • Be the first to comment

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>

×