Aula 07 - Testes de Software

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

*
*
*
Unidade 2 – Parte IV
Técnicas de 
Teste de Software
Peter Pedrycz
*
*
*
2.4 Tipos de Testes de Software
 Teste Funcional  são utilizados para exercitar o código com entradas nominais, para os quais os valores esperados estão disponíveis. Também são conhecidas as condições limite para elas.
 Teste de Desempenho  são utilizados para determinar o desempenho do software como o tempo de execução associado a várias partes do código, ao tempo de resposta (no caso de chamada a outros sistemas. O objetivo é identificar os pontos fracos e quantificar suas deficiências, levando a outras melhorias.
 Teste de Fadiga  São destinados a determinar os pontos fortes e as limitações do software.
*
*
*
Tipos de Testes de Software
 Teste de Estrutura  destinam-se ao exercício da lógica interna do software.
 Teste de pequena-grande escala  refere-se a parte do sistema que está sujeita ao teste. No caso de procedimentos e funções individuais, isso leva ao teste de pequena escala. O de grande escala é destinado principalmente ao teste de integração.
 Teste de Caixa preta-caixa branca  o critério que leva a esse tipo de discriminação indica se a estrutura interna (lógica) do sistema está disponível para fins de teste.
*
*
*
Teste de Condições Limite
 Geralmente, o teste de caixa branca não testa os casos que não sejam explicitamente visíveis ou enfatizados. Por exemplo, vamos imaginar dois sensores que controlam as comportas de uma usina hidrelétrica e a seguinte instrução:
if (x > y) then S1 else S2
O caso x = y nunca está sendo explicitamente testado. É possível que haja um modo em que a igualdade é percebida e modificar a parte da condição da declaração original, se o entendimento do programa não atender aos requisitos ou ocorrer a existência de algumas questões de implementação.
*
*
*
Teste de Condições Limite
A análise do valor limite leva a novos casos de teste referentes a valores adjacentes aos limites. A seleção de tais casos adicionais, aumentam a probabilidade de se detectar uma falha.
Qualquer número
(neste intervalo)
*
*
*
Teste Exaustivo
Este teste pertence à categoria de teste de caixa-preta. Apesar de totalmente impraticável, ele permite uma melhor compreensão da complexidade do teste e quantifica limites de sua utilidade prática. Em resumo, um teste exaustivo deve mostrar que o código está correto para todas as entradas possíveis.
*
*
*
Teste Estrutural
Este teste pertence à categoria de teste de caixa-branca. Neste teste, estamos interessados no desenvolvimento de casos de teste baseados na estrutura (lógica interna) do código em teste. Existem diversas classes de teste que dependem de quão completo e consumidor de tempo o processo de teste deva ser.
 
Abrangência de instrução - requer que toda instrução tenha sido executada pelo menos uma vez.
Begin
 if (y>= 0) then y = 0 - y;
 abs = y;
end;
*
*
*
Teste Estrutural
Abrangência de ramificação - isto requer que cada instrução de decisão seja avaliada como verdadeira ou falsa pelo menos uma vez.
sim
sim
sim
sim
não
não
não
não
*
*
*
Teste Estrutural
Abrangência de ramificação/condição - cada ramificação deve ser executada pelo menos uma vez e todas as combinações possíveis devem ser exercitadas.
sim
sim
não
não
Obs.: V V
 F F
 V F
 F V
*
*
*
Teste Estrutural
Abrangência de Caminho - considera todos os caminhos lógicos possíveis em um programa e leva a casos de teste com intuito de exercitar cada caminho. Em muitos casos é impraticável, principalmente quando ocorrem muitos loops no programa
sim
não
sim
não
*
*
*
Teste de Regressão
Seu objetivo é o de reexecutar automaticamente alguns testes sempre que uma pequena mudança ocorrer no software.
Principais etapas: 
 Captura de um teste (ou bateria de testes) para reprodução. Todos devem passar por um grupo de testes fortes (aqueles com alto nível de abrangência;
Comparação de novas saídas (respostas) com respostas antigas para garantir que não haja mudanças indesejadas.
*
*
*
Teste de Software Estático
 Ao contrário das formas dinâmicas, este teste não trata da execução do código. Assim sendo, é caracterizada como um método de “teste off-line”. Existem duas classes de técnicas:
 Informal - inclui inspeções e revisões estruturadas (walkthrough);
 Formal - inclui provas de correção e execução simbólicas.
*
*
*
Teste de Software Estático - Informal
	São geralmente identificadas com inspeções e revisões de código. A diferença essencial entre elas é que as inspeções de software são orientadas por feedback, enquanto as revisões de código promovem a interação entre os testadores, os membros da equipe do projeto e os demais participantes. É um método de exame caixa-branca.
*
*
*
Teste de Software Estático - Informal
I) Inspeções - são atividades executadas por uma equipe especializada de pessoas que revisam um projeto ou código, com o intuito de descobrir falhas no programa (nunca avaliar o programador). Nesta reunião, o programa será examinado segundo uma série de parâmetros previamente definidos. Possui cinco etapas formais:
 Síntese
 Preparação
 Inspeção
 Retrabalho
 Acompanhamento
*
*
*
Teste de Software Estático - Informal
 Síntese - concentra-se num resumo dos documentos a ser inspecionado.
 Preparação - os participantes tentam entender o documento em detalhes. A lista de tipos de falhas e a freqüência correspondente encontrada em inspeções recentes são úteis, uma vez que ajudam a se concentrar nas áreas mais propensas a erros.
 Inspeção - no início, um participante revisa o código com a equipe de inspeção. Cada participante prossegue com suas atividades, apresentando suas listas de verificação. O objetivo da inspeção é encontrar e documentar falhas e não removê-las. O líder (moderador) é responsável pela preparação do relatório de inspeção.
*
*
*
Teste de Software Estático - Informal
 Retrabalho - as falhas e os problemas observados na etapa anterior são solucionados.
 Acompanhamento - O moderador garante que todos os problemas foram solucionados. Todas as soluções devem ser verificadas para garantir que nenhuma nova falha tenha surgido. Se mais de 5% do material inspecionado tiver sido retrabalhado, a equipe se reúne novamente para uma nova inspeção de 100%.
A equipe responsável pela inspeção varia de tamanho conforme a complexidade do sistema, normalmente de 3 a 6 indivíduos. Por exemplo no caso de inspeção de projeto, um moderador, um projetista, um implementador e um testador.
*
*
*
Teste de Software Estático - Informal
Erros Comuns Detectados pelas inspeções de Código
 Variáveis não iniciadas
 Saltos para loops
 Loops intermináveis
 Índices fora dos limites
 Inconsistências entre parâmetros
Loop de feedback
Preparar material de 
revisão e distribuí-lo
Revisar encontro
Solucionar problemas
identificados na revisão
Parar
Outra
revisão
*
*
*
Teste de Software Estático - Informal
Razões para não efetuar correções durante a reunião de inspeção:
 Evitar discussões e divagações;
 Maximizar a produtividade;
 Impedir a introdução de falhas oriundas de precipitação;
 Assegurar que o resultado esteja dentro dos padrões de qualidade
*
*
*
Teste de Software Estático - Informal
	A inspeção é mais eficiente do que o teste, pois durante uma única inspeção, somos capazes de identificar diversas falhas e inadequações. Ao testarmos um programa , é normal sermos capazes de identificar uma única falha e isso mesmo se o teste tiver sido bem sucedido.
	Oferece vantagens além do controle de qualidade do programa, do tipo: inspeção de programas “resistentes a teste”, avaliação da manutenibilidade, treinamento de pessoal, etc.
*
*
*
Teste de Software Estático - Informal
II) Revisões ou Walkthrough - esse método é semelhante à inspeção. A principal diferença é que o walkthrough enfatiza a execução manual do programa ou de trechos do programa. São utilizados dados especificamente projetados para demonstrar o funcionamento do programa. São também examinadas as reações do programa
às diferentes ações do usuário, com o intuito de verificar se a interface programa/usuário é satisfatória.
*
*
*
Teste de Software Estático - Informal
Outra diferença entre inspeção e walkthrough consiste em que este se preocupa em evidenciar os efeitos de dados e ações específicos, enquanto que a inspeção se preocupa, apenas, em narrar o que o programa faz. A inspeção é, portanto, bem mais rápida e superficial. O walkthrough é recomendado e no exame de programas ou segmentos de programa complexos.