Aula09_TesteSoftware_Parte1_apremdeeghku
- 1. Teste de Software Engenharia de Software Profa. Dra. Elisa Yumi Nakagawa 1º semestre de 2016 Aspectos teóricos e empíricos de teste de cobertura de software Notas Didáticas do ICMC/USP (no. 31)
- 2. Tópicos da Aula Ø Teste de Software Ø Terminologia e Conceitos Básicos Ø Técnicas e Critérios de Teste Ø Técnicas Funcional, Estrutural e Baseada em Erros
- 3. Introdução Ø Garantia de Qualidade de Software Ø Conjunto de atividades técnicas aplicadas durante todo o processo de desenvolvimento Ø Objetivo Ø Garantir que tanto o processo de desenvolvimento quanto o produto de software atinjam os níveis de qualidade especificados Ø V&V – Verificação e Validação
- 4. Introdução Ø Validação: Assegurar que o produto final corresponda aos requisitos do usuário Ø Verificação: Assegurar consistência, completitude e corretitude do produto em cada fase e entre fases consecutivas do ciclo de vida do software Ø Teste: Examina o comportamento do produto por meio de sua execução (análise dinâmica) Estamos construindo o produto certo? Estamos construindo corretamente o produto?
- 5. Terminologia ØEngano x Defeito x Erro x Falha Ø Um engano introduz um defeito no software. Ø O defeito, quando ativado, pode produzir um erro. Ø O erro, se propagado até a saída do software, constitui uma falha. Engano introduz Saída Falha Erro propaga CAUSA CONSEQÜÊNCIA Defeito Erro produz
- 6. Terminologia Ø Defeito Erro Falha Ø Defeito: deficiência mecânica ou algorítmica que, se ativada, pode levar a uma falha Ø Instrução ou comando incorreto Ø Erro: item de informação ou estado de execução inconsistente Ø Falha: evento notável em que o sistema viola suas especificações
- 7. Defeitos no Processo de Desenvolvimento Ø A maior parte é de origem humana Ø São gerados na comunicação e na transformação de informações Ø Continuam presentes nos diversos produtos de software produzidos e liberados (10 defeitos a cada 1000 linhas de código) Ø A maioria encontra-se em partes do código raramente executadas
- 8. Defeitos no Processo de Desenvolvimento Ø Principal causa: tradução incorreta de informações Ø Quanto antes a presença dos defeitos for revelada, menor o custo de correção do defeito e maior a probabilidade de corrigi-lo corretamente Ø Solução: introduzir atividades de VV&T ao longo de todo o ciclo de desenvolvimento
- 9. Teste e Depuração Ø Teste Ø Depuração Processo de executar um programa com o objetivo de revelar a presença de erros. Após revelada a presença do erro, este deve ser encontrado e corrigido. Contribuem para aumentar a confiança de que o software desempenha as funções especificadas.
- 10. Teste de Software Ø Fundamental em todos os ramos de engenharia Ø Software: produto da Engenharia de Software Ø Atividade essencial para ascensão ao nível 3 do Modelo CMMI/SEI Ø Atividade relevante para avaliação da característica funcionalidade (ISO 9126, ISO 25010, ISO 25041)
- 11. PROCESSOS DE AQUISIÇÃO n Preparação da Aquisição n Seleção do Fornecedor n Contrato n Monitoramento do Fornecedor n Aceitação do Cliente PROCESSOS DE FORNECIMENTO n Proposta do Fornecedor n Liberação do Produto n Apoio a Aceitação do Produto PROCESSOS DE DESENVOLVIMENTO n Elicitação de Requisitos n Análise dos Requisitos do Sistema n Projeto Arquitetural do Sistema n Análise dos Requisitos de Software n Projeto do Software n Construção do Software n Integração do Software n Teste do Software n Integração do Sistema n Teste do Sistema n Instalação do Software n Manutenção do Software e do Sistema PROCESSOS DE OPERAÇÃO n Uso Operacional n Apoio ao Cliente PROCESSOS FUNDAMENTAIS PROCESSOS DE CONTROLE DA CONFIGURAÇÃO n Documentação n Gerenciamento da Configuração n Gerenciamento da resolução de problemas n Gerenciamento dos Pedidos de Alteração PROCESSOS DE GARANTIA DE QUALIDADE n Garantia da Qualidade n Verificação n Validação n Revisão Conjunta n Auditoria n Avaliação do produto PROCESSOS DE APOIO PROCESSOS DE GERÊNCIA n Alinhamento Organizacional n Gerenciamento da Organização n Gerenciamento do projeto n Gerenciamento da Qualidade n Gerenciamento de Risco n Medições PROCESSOS DE MELHORIA DE PROCESSO n Estabelecimento do Processo n Avaliação do Processo n Melhoria do Processo PROCESSOS DE RECURSOS E INFRAESTRUTURA n Gerenciamento de Recursos Humanos n Treinamento n Gerenciamento do Conhecimento n Infraestrutura PROCESSOS DE REUSO n Gerencia dos Ativos n Gerencia do Programa de Reuso n Engenharia de Domínio PROCESSOS ORGANIZACIONAIS Norma ISO 12207
- 12. Desafios do Teste Ø Todos já testaram algum produto de software... Quais foram os maiores desafios? Ø Alguns problemas comuns... Ø Não há tempo suficiente para o teste. Ø Muitas combinações de entrada para serem exercitadas. Ø Não há tempo para o teste exaustivo. Ø Dificuldade em determinar os resultados esperados para cada caso de teste. Ø Requisitos do software inexistentes ou que mudam rapidamente. Ø Não há treinamento no processo de teste. Ø Não há ferramenta de apoio. Ø Gerentes que desconhecem teste ou que não se preocupam com qualidade.
- 13. Teste de Software Ø Inexistência de erro: Ø Software é de alta qualidade? Ø Conjunto de casos de teste T é de baixa qualidade? ? D P X T Objetivo: revelar a presença de erros
- 14. Teste de Software Ø Defeitos e erros não revelados Ø Falhas se manifestam durante a utilização pelos usuários Ø Erros devem ser corrigidos durante a manutenção Ø Alto custo
- 15. Teste de Software Ø Falhas graves Ø Qualidade e confiabilidade suspeitas Ø Modificação do projeto Ø Novos testes Ø Erros de fácil correção Ø Funções aparentemente funcionam bem Ø Qualidade e confiabilidade aceitáveis Ø Testes inadequados para revelar a presença de erros graves Ø Novos testes
- 16. Teste de Software Ø Fases de Teste Ø Teste de Unidade Ø Identificar erros de lógica e de implementação em cada módulo do software, separadamente Ø Teste de Integração Ø Identificar erros associados às interfaces entre os módulos do software Ø Teste de Sistema Ø Verificar se as funções estão de acordo com a especificação e se todos os elementos do sistema combinam-se adequadamente
- 17. Teste de Software Ø Etapas do Teste Ø Planejamento Ø Projeto de casos de teste Ø Execução do programa com os casos de teste Ø Análise de resultados
- 18. Teste de Software Ø Caso de teste Ø 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 Ø Oráculo Ø Um bom caso de teste tem alta probabilidade de revelar um erro ainda não descoberto
- 19. Teste de Software Ø Projeto de casos de teste Ø Pode ser tão difícil quanto o projeto do próprio produto a ser testado Ø Poucos programadores/analistas gostam de teste e, menos ainda, do projeto de casos de teste Ø É um dos melhores mecanismos para a prevenção de defeitos Ø É tão eficaz em identificar erros quanto a execução dos casos de teste projetados
- 20. Teste de Software Ø Maneira sistemática e planejada para conduzir os testes Ø Técnicas e Critérios de Teste Ø Conjunto de Casos de Teste T Ø Características desejáveis Ø Deve ser finito Ø Custo de aplicação deve ser razoável
- 21. Técnicas e Critérios de Teste Ø Critério de Teste C Ø Objetivo Ø Obter, de maneira sistemática, um conjunto T de casos de teste que seja efetivo quanto à meta principal de teste (revelar a presença de erros no programa) Ø Propriedades i) incluir todos os desvios de fluxo de execução ii) incluir pelo menos um uso de todo resultado computacional iii) T mínimo e finito
- 22. Técnicas e Critérios de Teste Ø Critério de Seleção de Casos de Teste Ø Procedimento para escolher casos de teste para o teste de P Ø Critério de Adequação Ø Predicado para avaliar T no teste de P Ø T é C-adequado ⇔ todo elemento requerido por C é exercitado por pelo menos por um t, t ∈ T
- 23. Técnicas e Critérios de Teste Ø Técnica Funcional Ø Requisitos funcionais do software Ø Critério Particionamento em Classes de Equivalência Ø Técnica Estrutural Ø Estrutura interna do programa Ø Critérios Baseados em Fluxo de Dados Ø Técnica Baseada em Erros Ø Erros mais freqüentes cometidos durante o processo de desenvolvimento de software Ø Critério Análise de Mutantes
- 24. Automatização da Atividade de Teste Ø Ferramentas de Teste Ø Contribuem para reduzir as falhas produzidas pela intervenção humana Ø Aumento da qualidade e produtividade da atividade de teste Ø Aumento da confiabilidade do software Ø Facilitam a condução de estudos comparativos entre critérios Para a aplicação efetiva de um critério de teste faz-se necessário o uso de ferramentas automatizadas que apóiem a aplicação desse critério.
- 25. Exemplos de Ferramentas de Teste Ø Critérios Estruturais: Fluxo de Dados Ø Asset, Proteste – programas em Pascal Ø xSuds – programas em C, C++ e Cobol Ø Poke-Tool – programas em C, Cobol e Fortran Ø JaBUTi – Java Bytecode Ø Critérios Baseados em Mutação Ø Mothra – programas em Fortran Ø Proteum – programas em C (unidade) Ø Proteum/IM – programas em C (integração) Ø Proteum/RS – especificações
- 26. Técnica Funcional (Caixa Preta) Ø Baseia-se na especificação do software para derivar os requisitos de teste Ø Aborda o software de um ponto de vista macroscópico Ø Envolve dois passos principais: Ø Identificar as funções que o software deve realizar (especificação dos requisitos) Ø Criar casos de teste capazes de checar se essas funções estão sendo executadas corretamente
- 27. Técnica Funcional Ø Problema Ø Dificuldade em quantificar a atividade de teste: não se pode garantir que partes essenciais ou críticas do software foram executadas Ø Dificuldade de automatização Ø Critérios da Técnica Funcional Ø Particionamento em Classes de Equivalência Ø Análise do Valor Limite Ø Grafo de Causa-Efeito
- 28. Técnica Funcional: Exemplo Ø Particionamento em Classes de Equivalência Ø Divide o domínio de entrada do programa em classes de dados (classes de equivalências) Ø Os dados de teste são derivados a partir das classes de equivalência
- 29. Técnica Funcional: Exemplo Ø Passos Ø Identificar classes de equivalência Ø Condições de entrada Ø Classes válidas e inválidas Ø Definir os casos de teste Ø Enumeram-se as classes de equivalência Ø Casos de teste para as classes válidas Ø Casos de teste para as classes inválidas
- 30. Técnica Funcional: Exemplo Ø Especificação do programa Identifier O programa deve determinar se um identificador é válido ou não. Um identificador válido deve começar com uma letra e conter apenas letras ou dígitos. Além disso, deve ter no mínimo um caractere e no máximo seis caracteres de comprimento. Ø Exemplo abc12 (válido); cont*1 (inválido); 1soma (inválido); a123456 (inválido)
- 31. Técnica Funcional: Exemplo Ø Classes de equivalência Tamanho t do identificador Condições de Entrada Classes Válidas Classes Inválidas 1 ≤ t ≤ 6 (1) Primeiro caractere c é uma letra Só contém caracteres válidos t > 6 (2) Sim (3) Não (4) Sim (5) Não (6) Ø Exemplo de Conjunto de Casos de Teste Ø T0 = {(a1,Válido), (2B3, Inválido), (Z-12, Inválido), (A1b2C3d, Inválido)} (1, 3, 5) (4) (6) (2)
- 32. Exercício de Fixação Ø Projete casos de teste para o seguinte programa, usando o critério Particionamento em Classes de Equivalência: Ø O programa string solicita do usuário um inteiro positivo no intervalo entre 1 e 20 e, então, solicita uma cadeia de caracteres desse comprimento. Após isso, o programa solicita um caracter e retorna a posição na cadeia em que o caracter é encontrado pela primeira vez ou uma mensagem indicando que o caracter não está presente na cadeia.
- 33. Análise do Valor Limite Ø Complementa o Particionamento de Equivalência. Ø Fonte propícia a erros – os limites de uma classe ou partição de equivalência. Partição de Equivalência Limites
- 34. Exercício de Fixação Ø Projete casos de teste para o seguinte programa usando o critério Análise do Valor Limite: Ø O programa string solicita do usuário um inteiro positivo no intervalo entre 1 e 20 e, então, solicita uma cadeia de caracteres desse comprimento. Após isso, o programa solicita um caracter e retorna a posição na cadeia em que o caracter é encontrado pela primeira vez ou uma mensagem indicando que o caracter não está presente na cadeia.