Qualidade de Software
Testes de Software
Marcelo Marinho
Estamos vendo a causa ou a
conseqüência?
Motivação
• Ocorrência de falhas humanas no processo de desenvolvimento de software é considerável.
• Processo de testes é indispensável na garantia de qualidade de software.
• Custos associados às falhas de software justificam um processo de testes cuidadoso e bem planejado.
Motivação
• Clientes mais exigentes;
Motivação
• Segundo pesquisas do SEI ( Software Engineering
Institute):
– 30% dos projetos são cancelados antes de serem finalizados;
– 70% dos projetos falham nas entregas das funcionalidades esperadas;
– Os custos dos projetos extrapolam mais de 180% dos valores previstos;
– Empresas de nível 1 dedicam cerca de 55% dos esforços para corrigir defeitos;
– Esses índices vão sendo gradativamente reduzidos à medida que elas adotam um modelo de qualidade
Finalidade dos testes
• Averiguar se todos os requisitos do sistema foram corretamente implementados;
• Assegurar, na medida do possível, a qualidade e a corretude do software produzido;
Finalidade dos testes
• Assegurar a satisfação do cliente com o produto desenvolvido; • Identificar casos de teste com elevada probabilidade para
revelar erros ainda não descobertos (com quantidade mínima de tempo e esforço);
• Verificar a correta integração entre todos os componentes de software.
Eficácia de Testes
• A atividade de teste é o processo de executar um programa com a intenção de descobrir um erro;
• Um bom caso de teste é aquele que apresenta uma elevada probabilidade de revelar um erro ainda não descoberto;
• Um teste bem sucedido é aquele que revela um erro ainda não descoberto.
Padronização de Testes
• Sistemático
– Testes aleatórios não são suficientes
– Testes devem cobrir todos os fluxos possíveis do software – Testes devem representar situações de uso reais
• Documentado
– Que testes foram feitos, resultados, etc.
• Repetível
– Se encontrou ou não erro em determinada situação, deve-se poder repeti-lo
Abordagens de teste
• Abordagem funcional (“caixa preta”) • Abordagem Estrutural (“caixa branca”)
Abordagens de teste
• Abordagem funcional (“caixa preta”)
– Os testes são gerados a partir de uma análise dos relacionamentos entre os dados de entrada e saída, com base nos requisitos levantados com os usuários
• Especificação (pré e pós-condições)
– Geralmente é aplicado durante as últimas etapas do processo de teste
Abordagens de teste
• Abordagem funcional (“caixa preta”)
– Tem o objetivo de encontrar:
• Erros associados a não satisfação da especificação • Erros na GUI
• Erros nas estruturas de dados ou acesso ao banco de dados • Problemas de integração
Abordagens de teste
• Abordagem estrutural (“caixa branca”)
– Os testes são gerados a partir de uma análise dos caminhos lógicos possíveis de serem executados
– Conhecimento do funcionamento interno dos componentes do software é usado
Abordagens de teste
• Abordagem estrutural (“caixa branca”)
– Objetivo
• Garantir que todos os caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez
• Realizar todas as decisões lógicas para valores falsos e verdadeiros
• Executar laços dentro dos valores limites • Avaliar as estruturas de dados internas
Abordagens de teste
• Abordagem estrutural
– Programador
• Testa o programa em pedaços
• Encontra quais as partes do programa que já foram testadas
• Conhece quais partes do programa serão modificadas • Verifica os limites internos no código que são
invisíveis ao testador externo
Estágios de Teste
• Teste de Unidade • Teste de Aspectos OO • Teste de Integração • Teste de Sistema • Teste de AceitaçãoEstágios de teste
• Teste de unidade
– Visa testar individualmente cada um dos componentes (programas ou módulos);
– Componentes individuais (ex.: métodos, classes) são testados para assegurar que os mesmos operam de forma correta
• Teste de aspectos OO – Teste de Iteradores
Estágios de teste
• Teste de integração
– Visa testar o relacionamento entre as diversas unidades integradas. – Em outras palavras, garantir que a interface entre os módulos
funcione adequadamente. • Teste de sistema
– Conjunto de testes cujo objetivo primordial é colocar completamente à prova todo o sistema.
– Em outras palavras, testa a integração do software com o ambiente operacional – hardware,pessoas e dados reais;
Estágios de teste
• Testes de aceitação (Homologação)
– São testes realizados pelo cliente/usuário com o objetivo de validar o sistema a ser implantado.
– A motivação maior para esses testes é o fato do desenvolvedor nunca conseguir prever como o usuário realmente usará um software numa situação real.
Estágios de teste
• Testes de aceitação (Homologação) – Podem ser de duas categorias:
• Testes alfa • Testes beta
Estágios de teste
• Testes de aceitação (Homologação)
– Testes alfa: são feitos por um determinado cliente, geralmente nas
instalações do desenvolvedor, que observa e registra os erros e/ou problemas;
– Testes beta: são realizados por possíveis clientes, em suas próprias
instalações, sem a supervisão do desenvolvedor. Cada cliente relata os problemas encontrados ao desenvolvedor, posteriormente.
Tipos de Teste
• Existem vários tipos de teste que podem ser
executados nos diversos estágios de
– Teste funcional
– Teste de recuperação de falhas – Teste de segurança
– Teste de carga
– Teste de desempenho – Teste de portabilidade
Tipos de teste
• Teste funcional (regras de negócio)
– Testa a funcionalidade geral do sistema, em termos de regras de negócio (fluxo de trabalho), considerando-se tanto as condições válidas como as inválidas;
Tipos de teste
• Teste de recuperação de falhas
– O software é forçado a falhar de diversas maneiras para que seja verificado o seu comportamento;
Tipos de teste
• Teste de segurança e controle de acesso
– Tenta certificar-se de que todos os mecanismos de proteção embutidos no software, de fato, o protegerão dos acessos indevidos;
Tipos de teste
• Teste de carga
– Tenta confrontar o software ou os programas com situações anormais. Ele executa o software de uma forma que exige recursos em quantidade, freqüência e volume bem maiores do que o uso normal;
Tipos de teste
• Teste de desempenho
– São testes que visam verificar o desempenho ou performance do software.
– Verifica o tempo de resposta e processamento (para diferentes configurações, número de usuários, tamanho do BD, etc.)
– Exemplo
Tipos de teste
• Teste de portabilidade
– Verifica o funcionamento adequado do sistema em diferentes configurações de hardware/software.
– O que testar
• Compatibilidade do software/hardware; • Configuração do servidor;
• Tipos de conexões com a Internet; • Compatibilidade com o browser;
Tipos de teste
• Teste de estresse
– Verifica a funcionalidade do sistema em situações limite • Pouca memória ou área em disco, alta competição por recursos
compartilhados (ex: vários acessos/transações no BD ou rede)
• Exemplo: pode-se desejar saber se um sistema de transações
bancárias suporta uma carga de mais de 100 transações por segundo ou se um sistema operacional pode manipular mais de 200 terminais remotos
Tipos de teste
• Teste de instalação e desinstalação
– Verifica a correta instalação e desinstalação do sistema para diferentes plataformas de hardware/software e opções de instalação
– O que testar
• Compatibilidade do hardware e software
• Funcionalidade do instalador/desinstalador sob múltiplas opções/condições de instalação
Processo de Testes
• Testes também é o processo de avaliar a qualidade de um software;
• O processo de testes define como os testes serão planejados, projetados, implementados, executados e avaliados através de um conjunto de atividades, artefatos e papéis;
• A seguir serão apresentadas algumas das possíveis atividades de um processo de testes.
Atividade - Planejar Testes
•Objetivo: planejar as atividades de testes que serão executadas ao longo de todo o ciclo de vida do projeto.
Entradas Plano do Projeto
Cronograma do Projeto Planilha de Riscos
Documento de Requisitos do Cliente. Documento de Requisitos do Produto (se existir)
Planejar Testes
Saídas Plano de Testes (revisado)
Cronograma (atualizado, se necessário). Planilha de Riscos (atualizada, se necessário)
Atividade - Projetar Testes
• Objetivo: identificar e especificar os casos de testes baseando-se nos requisitos e na estratégia descrita no Plano de Testes.
Entradas
Documento de Requisitos do Cliente. Documento de Requisitos do Produto (se existir) Documento de Arquitetura Plano de Testes Plano do Projeto Manual de Instalação Projetar Testes Saídas Projeto de Testes (revisado)
Plano de Testes (atualizado, se necessário) MRT (atualizada, se existir)
Atividade - Implementar
Testes
•Objetivo: implementar scripts de automação para utilizar na execução dos casos de teste.
Entradas
Documento de Requisitos do Cliente. Documento de Requisitos do Produto (se existir)
Documento de Arquitetura Plano de Testes
Projeto de Testes
Especificações de Componentes (opcional).
Implementar Testes
Saídas
Projeto de Testes (atualizado, se necessário) Scripts de Automação (revisados)
Atividade - Executar
Testes
•Objetivo: executar os casos de teste projetados e registrar os seus resultados.
Entradas
Documento de Requisitos do Cliente
Documento de Requisitos do Produto (se existir) Projeto de Testes
Planilha de Resultados
Scripts de Teste (caso haja automação) Produto a ser testado (baselined)
Manual de Instalação
Executar Testes
Saídas
Planilha de Resultados (atualizada) Log de execução dos testes (caso haja automação)
Atividade - Analisar Testes
•Objetivos: Consolidar os dados operacionais do processo de teste em informações gerenciais que complementem a tomada de decisões.
Entradas Planilha de Resultados Plano de Testes
Projeto de Testes
Analisar Resultado dos Testes
Saídas
Planilha de Resultados (atualizada)
Plano de Testes (atualizado, se necessário) Projeto de Testes (atualizado, se necessário)
