TESTES DE SOFTWARE – AULA 3 Prof. Me. Ronnison Reges Vidal Revisão, 2016 TESTE NO PROGRAMA TESTE CAIXA BRANCA E TESTE CAIXA PRETA OBJETIVOS DESTA AULA 1. Compreender os testes de interior do programa; 2. Definir testes para o interior do programa; 3. Implementar testes para o interior do programa; 4. Avaliar testes realizados no interior do programa. 3 INTRODUÇÃO Uma vez gerado o código-fonte, o software deve ser testado para descobrir (e corrigir) tantos erros quanto possível antes de fornecê-lo ao cliente. O objetivo do teste é encontrar erros, e um bom teste é aquele que tem alta probabilidade de encontrar um erro. Devem ter uma serie de características que permitam atingir o objetivo de encontrar o maior número de erros com o mínimo de esforços. 4 INTRODUÇÃO Testes podem ser usados para descobrir a presença de erros, mas não para mostrar a sua ausência. Testes de software é o processo de executar o software de uma maneira controlada com o objetivo de descobrir diferenças entre o comportamento previsto e o comportamento observado. Um teste bem-sucedido é aquele que revela um erro ainda não descoberto. 5 INTRODUÇÃO Devemos projetar testes que tenham a mais alta probabilidade de descobrir a maioria dos erros com uma quantidade mínima de tempo e esforço; Os métodos de projeto de casos de teste oferecem ao desenvolvedor uma abordagem sistemática ao teste. Oferecem ainda um mecanismo que ajuda a garantir a integridade do teste e proporciona a mais alta probabilidade de revelar erros no software. 6 PROJETOS DE CASOS TESTE Qualquer produto trabalhado por engenharia pode ser testado de duas maneiras: 1 - Conhecendo-se a função específica que um produto projetado deve executar, testes podem ser realizados para demonstrar que cada função operacional; Abordagem: Teste de Caixa Preta 7 é totalmente PROJETOS DE CASOS TESTE 2 - Conhecendo-se o funcionamento interno de um produto, testes podem ser realizados para garantir que a operação interna do mesmo tenha desempenho de acordo com as especificações e que os componentes internos foram postos à prova. Abordagem: Teste de Caixa Branca 8 TESTE CAIXA BRANCA Teste de caixa branca é uma abordagem de projeto de casos de teste que usa a estrutura de controle do projeto procedimental para derivar casos de teste. Baseia-se num procedimentais. 9 minucioso exame dos detalhes TESTE CAIXA BRANCA Os caminhos lógicos através do software são testados, fornecendo-se casos de teste que põem à prova conjuntos específicos de condições e/ou laços. O status do programa pode ser examinado em vários pontos para determinar se o esperado corresponde ao real. 10 TESTE CAIXA BRANCA Com este método nós podemos projetar casos de teste que: Garantam que todos os caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez; Exercitem todas as decisões lógicas para valores falsos ou verdadeiros; Executem todos os laços em suas fronteiras e dentro de seus limites operacionais; Exercitem as estruturas de dados internas para garantir a 11 sua validade. TESTE CAIXA BRANCA Tipos de Teste Caixa Branca: Teste de Caminho Básico Teste de Condição Teste de Fluxo de Dados Teste de Ciclo 12 TESTE DO CAMINHO BÁSICO Técnica de teste de caixa branca inicialmente proposta por Tom McCabe. Permite ao projetista do caso de teste derivar uma medida da complexidade lógica de um projeto procedimental e usála para definir um conjunto básico de caminhos de execução; A Complexidade Ciclomática é uma métrica que proporciona uma medida quantitativa da complexidade lógica de um programa. 13 TESTE DO CAMINHO BÁSICO Os casos de teste projetados para exercitarem este conjunto básico têm garantia de executar cada instrução do programa pelo menos uma vez durante a atividade de teste. Os seguintes passos devem ser aplicados: 14 TESTE DO CAMINHO BÁSICO 1. Usando o projeto ou o código como base, desenhar o grafo de fluxo correspondente; 2. Determinar a complexidade ciclomática do diagrama de fluxo resultante. 3. Determinar um conjunto base de caminhos linearmente independentes. 4. Preparar casos de teste que vão forçar a execução de cada caminho do conjunto base. 15 TESTE DO CAMINHO BÁSICO Exemplo: Segmento de programa fonte e seu correspondente grafo de fluxo. procedure:sort 1: do while records remain read record; 2: if record field1 = 0 1 3: then process record; store in buffer; 2 increment counter; 4 3 4: else if record field2 = 0 5: then reset counter; 6 5 6: else process record; store in file; 7 7: endif 8 endif 8: enddo 9 9: end 16 TESTE DO CAMINHO BÁSICO Caminho 1: 1-9 Caminho 2: 1-2-3-8-1 ... Caminho 3: 1-2-4-5-7-8-1 ... Caminho 4: 1-2-4-6-7-8-1 ... 1 2 4 6 R3 5 3 R2 7 8 9 17 R4 R1 TESTE DE CONDIÇÃO Método de Projeto de casos de teste que põe à prova as condições lógicas contidas em um módulo de programa. Condição Simples: variável booleana ou expressão relacional, precedida ou não por um operador NOT (‘) Condição Composta: duas ou mais condições simples, operadores booleanos e parênteses. Tipos de Erros de uma Condição: erro de operador booleano, erro de variável booleana, erro de parênteses booleano, erro de operador relacional, erro de expressão aritmética. 18 TESTE DE CONDIÇÃO Teste de Ramos: Para uma condição C composta, os ramos verdadeiro e falso de C e todas as condições simples em C precisam ser executadas pelo menos uma vez. Teste de Domínio: requer 3 ou 4 testes sejam derivados para uma expressão relacional. 19 TESTE DE DOMÍNIO Para uma expressão E1 <operador relacional> E2 3 testes são exigidos para tornar o valor de E1 >, = ou < que o de E2. Se <operador relacional> estiver incorreto e E1,E2 corretos, esses 3 testes garantem a detecção de erro de operador relacional. Para detectar erros em E1 e E2, basta executar um teste que faça o valor de E1 > ou < que o de E2, com uma diferença menor possível. 20 TESTE DE CICLO (LAÇOS) Fundamental para a grande maioria de todos os algoritmos implementados no software. Técnica que concentra na validade das construções de laços. Laços Simples: deve ser aplicado o seguinte conjunto de teste: •Pule o laço inteiramente; •Somente uma passagem através do laço; •Duas passagens através do laço; •m passagens através do laço, onde m < n; •n-1, n, n+1 passagens através do laço. 21 21 TESTE DE CICLO (LAÇOS) Laços Aninhados: 1.Inicie pelo laço mais interno. Fixe os outros laços para valores mínimos. 2.Realize testes de laços simples para o laço mais interno. 3.Trabalhe para fora, realizando testes para o laço seguinte, mas mantendo todos os ciclos externos nos valores mínimos 4.Continue até que todos os laços tenham sido testados. 22 TESTE DE CICLO (LAÇOS) Laços Concatenados: 1. Se laços independentes dos demais: usar abordagem de laços simples. 2. Se contador de laços para o laço 1 for usado como valor inicial para o laço 2: usar abordagem de laços aninhados. 23 TESTE DE CICLO (LAÇOS) Laços não estruturados: Sempre que possível, esta classe deve ser reprojetada para refletir o uso das construções de programação estruturada. 24 TESTE CAIXA PRETA Foco: requisitos funcionais do software Possibilita a derivação de conjuntos de condições de entrada que exercitem todos os requisitos funcionais para um programa. O Teste de Caixa Preta desconsidera a estrutura de controle. A atenção é voltada ao domínio da informação. 25 TESTE CAIXA PRETA O Teste de Caixa Preta não é uma alternativa às técnicas Caixa Branca, mas ao contrário, é uma abordagem complementar, que mais provavelmente descobrirá uma classe diferente de erros. 26 TESTE CAIXA PRETA Também chamados de testes funcionais, pois a especificação funcional é usada para derivar os casos de teste Especificação funcional muitas vezes pode ser completada ou criada pelo projetista de testes Efeito colateral benéfico: ajuda a revelar falhas na especificação 27 TESTE CAIXA PRETA Projeto de casos de testes pode começar desde cedo – E continua ao longo do desenvolvimento – Aplicáveis em todas as fases de testes: unidades → sistemas Prescindem do código fonte: – Úteis quando código fonte não está disponível (ex.: uso de componentes de terceiros) – Podem ser usados quando código muito complexo (ex.: testes de sistemas 28 TESTE CAIXA PRETA São realizados para responder as seguintes perguntas: Como a validade funcional é testada? Como o comportamento e o desempenho é testado? Que classes de entrada farão bons casos de teste? O sistema é particularmente sensível a certos valores? Como as fronteiras de uma classe de dados é isolada? Que taxas e volumes de dados o sistema pode tolerar? Que efeito as combinações específicas de dados terão sobre a operação do sistema? 29 TESTE CAIXA PRETA Desta forma o teste de caixa preta tenta encontrar erros nas seguintes categorias: Funções incorretas ou faltando; Erros de interface; Erros em estruturas de dados ou acesso a bases de dados externas; Erros de comportamento ou de desempenho; Erros de inicialização e término. 30 TESTE CAIXA PRETA Existem diferentes métodos de testes de caixa preta que podem ser subdivididos em: Particionamento em Equivalência Análise do Valor Limite Teste de Matriz Ortogonal Baseado em Grafo 31 TESTE CAIXA PRETA Particionamento de Equivalência Método de teste de caixa preta que divide o domínio de entrada de um programa em classes de dados a partir das quais os casos de testes podem ser derivados. Um caso de teste ideal descobre sozinho uma classe de erros que, de outro modo, poderia exigir que muitos casos fossem executados antes que o erro geral fosse observado. 32 TESTE CAIXA PRETA Particionamento de Equivalência O Particionamento de Equivalência divide o domínio de entrada em uma série de diferentes classes (ex: números positivos, strings sem ’brancos’). Um caso de teste ideal descobre sozinho uma classe de erros. 33 TESTE CAIXA PRETA Particionamento de Equivalência As classes de equivalência podem ser definidas, conforme as seguintes diretrizes: 1. Se uma condição de entrada especificar um intervalo, uma classe de equivalência válida e duas classes de equivalência inválidas são definidas. 2. Se uma condição de entrada exigir um valor específico, uma classe de equivalência válida e duas inválidas são definidas. 34 TESTE CAIXA PRETA Particionamento de Equivalência As classes de equivalência podem ser definidas, conforme as seguintes diretrizes: 3. Se uma condição de entrada especificar um membro de um conjunto, uma classe de equivalência válida e uma inválida são definidas. 4. Se uma condição de entrada for booleana, uma classe de equivalência válida e uma inválida são definidas. 35 TESTE CAIXA PRETA Análise do Valor Limite Percebe-se que um número maior de erros tende a ocorrer mais nas fronteiras do domínio de entrada do que no “centro”. A análise de valor de limite leva à escolha de casos de teste que põem à prova os valores fronteiriços. É uma técnica que complementa o particionamento de equivalência: em vez de selecionar qualquer elemento de uma classe de equivalência, a BVA (boundary-value analysis) leva à seleção de casos de teste nas 36 “extremidades”da classe. TESTE CAIXA PRETA Análise do Valor Limite Qualquer número (neste intervalo) 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. 37 TESTE CAIXA PRETA Diretrizes para BVA Se uma condição de entrada especifica um intervalo: 1. Casos de teste com o valores a e b, e imediatamente acima e abaixo são planejados. 2. Se uma condição de entrada especifica vários valores: • Casos de teste devem ser desenvolvidos para exercitar o mínimo e o máximo. • Valores imediatamente acima e abaixo também 38 devem ser testados. TESTE CAIXA PRETA Diretrizes para BVA Aplique as diretrizes 1 e 2 às condições de saída. • Exemplo: a saída de um programa é uma tabela de dados. Casos de teste devem ser criados para gerar tabelas com o mínimo e o máximo de linhas e colunas. 4. Se as estruturas de dados internas do programa têm limites definidos, testes devem ser projetados para exercitar os limites internos 39 TESTE CAIXA PRETA Teste de matriz ortogonal O teste de matriz ortogonal pode ser aplicado a problemas nos quais o domínio de entrada é relativamente pequeno, mas muito grande para acomodar um teste exaustivo. O objetivo do teste é a construção de caso de teste com uma visualização geométrica associada aos valores de entrada de uma aplicação. 40 TESTE CAIXA PRETA Teste de matriz ortogonal Se o domínio de entrada é limitado, é possível realizar testes exaustivos de todos as combinações de valores de entrada. – Exemplo: três parâmetros que assumem três valores discretos cada um (3×3×3 = 27 casos de teste). • Para domínios de entrada muito grandes, uma abordagem comum é variar um parâmetro de cada vez. – Não detecta interações entre parâmetros • O teste de matriz ortogonal é um meio termo, aplicável a problemas com domínio de entrada relativamente pequeno, mas grande demais para testes exaustivos. 41 TESTE CAIXA PRETA Para ilustrar, vamos considerar a função envie para uma aplicação de fax. Neste exemplo, são passados quatro parâmetros: P1, P2, P3 e P4. Cada parâmetro assume três valores discretos. P1 assume, por exemplo, os valores: P1=1, enviar agora; P1=2, enviar após 1 hora; P1=3, enviar depois da meia-noite; P2, P3 e P4 também assumiriam valores, 1, 2 e 3, significando outras funções de envio. 42 TESTE CAIXA PRETA Matriz ortogonal para a função envie da aplicação de fax: Parâmetros de Teste Casos de Teste P1 P2 P3 P4 1 1 1 1 1 2 1 2 2 2 3 1 3 3 3 4 2 1 2 3 5 2 2 3 1 6 2 3 1 2 7 3 1 3 2 8 3 2 1 3 9 3 3 2 1 43 TESTE CAIXA PRETA Matriz Ortogonal Casos de teste ficam espalhados uniformemente pelo domínio de teste. • Detecta e isola todas as falhas de modo singular. – Pela análise da informação sobre quais testes revelam erros, pode-se identificar quais valores de parâmetro causam a falha. • Detecta todas as falhas de modo duplo. • Falhas multi-modo podem ou não ser detectadas. 44 TESTE CAIXA PRETA Baseado em grafo O teste baseado em grafos leva em consideração os objetos modelados no software e as relações que os unem. A ideia é definir uma série de testes que verificam se os objetos têm a relação esperada uns com outros. Um grafo é uma coleção de nós que representam objetos, ligações que representam as relações entre objetos, peso de nó que descreve as propriedades de um nó e pesos de ligação que descrevem uma característica de uma ligação. 45 TESTE CAIXA PRETA Baseado em grafo O primeiro passo no teste é entender os objetos que estão modelados no softwaree as relações entre eles. – Para isso, o engenheiro cria um grafo onde cada nó representa um objeto e cada aresta representa uma relação entre os objetos. • Depois disso, uma série de testes é criada para cobrir o grafo de modo que cada objeto e cada relação seja exercitada 46 TESTE CAIXA PRETA Baseado em grafo 47 TESTE CAIXA PRETA Tipos de Modelagem em grafo Modelagem de fluxo de transação Nós representam passos em alguma transação. Arestas representam as conexões lógicas entre os passos. Modelagem de estado finito Nós representam diferentes estados do software observáveis pelo usuário. Arestas representam transições de um estado para outro. Modelagem de fluxo de dados Nós representam os objetos de dados. Arestas representam as transformações que ocorrem para traduzir um objeto em outro. Eg: FTW = 0,62 x GW Modelagem de tempo Nós representam objetos do programa. Arestas representam ligações seqüenciais entre esses objetos. 48 Pesos são usados para especificar os tempos de execução.