Baixe o app para aproveitar ainda mais
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.
Compartilhar