Teste de Software. Objetivos e Limites. Objetivos e Limites. Objetivos e Limites. Objetivos e Limites. Objetivos e Limites

Transcrição

1 Teste de Software Prof. Avelino F. Zorzo PUCRS Elaborado inicialmente pelo prof. Bernardo Copstein Teste é uma coisa óbvia? Qual a complexidade da questão? tá pronto, profi, é só testar... ué, mas pra 1 funciona... O que significa dizer: o programa funciona? Especificação: conjunto de dados de entrada e comportamento esperado. Programa: conjunto de computações a serem executadas quando o mesmo for alimentado com dados de entrada. Um programa funciona, ou melhor, está correto em relação ao que foi especificado se o comportamento do mesmo fecha com o previsto na especificação para todas as entradas possíveis. É fácil verificar se um programa funciona? Qual a complexidade da questão? Verifique a complexidade da questão: escreva um conjunto de testes para o programa implementado a partir da especificação abaixo: Um programa recebe pela linha de comando três valores inteiros. Os três valores devem ser interpretados como sendo os comprimentos dos lados de um triângulo. O programa deve imprimir uma mensagem dizendo se o triângulo é equilátero, isóceles ou escaleno. É possível garantir que o programa está correto? Pode-se prever todas as possibilidades de combinações de valores de entrada? Qual o tamanho do buffer do sistema operacional? O esforço vale a pena? Mostrar que um programa está correto é um problema não computável. Mesmo que a partir de um conjunto de casos de teste seja possível detectar e eliminar todos os bugs de um sistema não é possível saber disso. A dúvida sobre a existência de bugs irá permanecer. Quais são então os objetivos da atividade de teste? 1

2 Objetivos da atividade de teste: Revelar a existência de falhas. Avaliar a qualidade do produto. Teste de software é a atividade de executar um programa com o objetivo de revelar a existência de falhas e avaliar sua qualidade Não é possível eliminar todos os problemas de um sistema apenas com testes, mas pode-se reduzir significativamente sua ocorrência. Teste permite trabalhar com parâmetros de qualidade. Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um problema. O teste bem sucedido é o que revela a existência de uma falha ainda não descoberta. Conceitos Falha x Erro x Defeito Verificação x Validação Verificação: estamos construindo certo o produto? Validação: estamos construindo o produto certo? Teste X Qualidade Qualidade é um conceito mais amplo Teste gera informação sobre qualidade do produto Conceitos Oráculo de teste: É o que permite determinar se um teste passou ou falhou. Ambiente de teste: Hw+Sw necessário para o teste. Teste Agrega Valor Muitos profissionais tem dificuldade em enxergar valor agregado à atividade de teste Valor: Detectam-se falhas Gera-se informações a respeito da qualidade do produto A liberação das versões passa a ser gerenciada Sistemas mission critical : uma questão de ética Exigência de mercado Teste no Ciclo de Desenvolvimento de Software 2

3 Especificação de Requisitos Projeto Implementação Modelo de desenvolvimento de software tradicional: Testes Cada etapa do ciclo de desenvolvimento tem um custo relativo Se manutenção é a mais cara, teste responde por 45% do desenvolvimento. Etapa Custo Relativo Análise 3% Projeto 8% Implementação 7% Teste 15% Manutenção 67% Operação e Manutenção O teste e o reparo de problemas podem ser feitos a qualquer momento ao longo do ciclo de vida O custo da detecção cresce a medida que o ciclo de vida avança. Evolução do custo segundo Bohem: Alterar o documento de especificação de requisitos em sua primeira revisão praticamente não tem custo; Consertar bugs quando o próprio programador os detecta tem custo baixo: não existe custo de comunicação; o bug não tem de ser explicado para ninguém; não existe a necessidade de cadastrá-lo em um sistema de acompanhamento; não existe a necessidade de re-teste por parte de uma equipe de testadores; não precisa atualizar o bug status ; a falha não influencia o trabalho de mais ninguém. Consertar uma falha antes que o programa seja liberado é muito mais barato do que enviar novos discos ou um técnico para instalar um patch. Além disso, evitam-se arranhões na imagem da empresa e do produto. Especificação de Requisitos Projeto Implementação Testes caixa branca Testes Testes caixa preta Operação e Manutenção 3

4 Teste na especificação Os requisitos são Corretos? Consistentes (não-contraditórios)? Completos? Viáveis? Testáveis? Teste no projeto Revisão do projeto Consistência interna Verificação em relação à especificação Projeto visando testabilidade Teste na implementação Costuma ser confundido com depuração Técnicas estruturais e estratégias de unidade e integração Teste de sistema Execução dos testes Relatório de falhas Eliminação de falhas (bug fixing) Re-teste (teste de regressão) Coordenado pelo engenheiro de teste Executado pelo testador Manutenção Defeitos reportados pelos usuários Classificação de falhas Classificação das Falhas Origem das falhas: Formação do pessoal Problemas de comunicação Enganos ou esquecimentos O processo Importância da classificação Identificação de problemas recorrentes Criação de testes focados nas áreas com maiores probabilidades de falha Diferentes autores sugerem diferentes classificações Classificação das Falhas Sugestão de classificação (Burnstein) Falhas relacionadas a fase de análise Falha na descrição funcional Falha no detalhamento das funcionalidades Falha na descrição das dependências entre funcionalidades Falha na descrição das interfaces Falhas relacionadas ao projeto Falha nos algoritmos Falha de controle, lógica ou seqüência Falha nas estruturas de dados Falha na descrição das interfaces Falha na descrição funcional Falha na interface externa 4

5 Classificação das Falhas Falhas no código Falhas no algoritmo Falhas de controle, lógica ou seqüência Falhas de inicialização Falhas de fluxo de dados Falhas nas estruturas de dados Falhas na interface dos módulos Falhas na documentação Falhas de Hw ou Sw externo Categorias de teste classificam os testes com base: na informação (entrada) usada para definir os casos de teste, e/ou Nas características do produto que se deseja avaliar (informação desejada na saída) Níveis de teste atividades (etapas) que podemos escolher para compor o processo de teste Classificações são ortogonais Categorias: Categorias e níveis de teste Funcional (black-box) Desempenho Baseada na especificação (performance) Estrutural (white-box) enfoque na medição de parâmetros de eficiência Baseada no código Stress Estatístico enfoque nos parâmetros Enfoque na confiabilidade de sobrecarga Categorias não são estanques: performance confunde-se com stress segundo uma definição mais rígida, performance nem seria considerado teste teste estatístico e estrutural também usam informações da especificação categorias específicas (dependentes de domínio): localização, instalação, impressão, conformidade com padrões, etc. cada categoria inclui diversas técnicas Níveis: 5

6 Unidade Integração Sistema Estrutural X X Funcional X X X Performance X Stress X Estatístico X Teste de unidade cada componente testado em separado definição de componente variável classe (OO), módulo, procedimento,... Necessidade: especificação por componente Frameworks: Junit, CppUnit, YakTest, SQLUnit, Teste de integração Testa-se as interfaces entre os componentes necessita muita informação estrutural: arquitetura especificação das interfaces técnicas: big bang incremental Teste de sistema: Extremo do teste de integração Geralmente é o primeiro a ser implantado Pode ser usado como teste de aceitação Teste: Resumo Requisitos Plano de testes Projeto Implementação Teste unitário/integração Obrigado! Testes Teste funcional Manutenção Teste estatístico Teste de performance Teste de stress Outros aspectos 6