Técnicas de Teste de Software Pressman 1

Teste de Software 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 tem uma elevada probabilidade de revelar um erro ainda não descoberto um teste bem-sucedido é aquele que revela um erro ainda não descoberto. 2

Teste de Software “Se realmente fossemos bons para programar não haveriam bugs. Se existem bugs, é porque somos ruins naquilo que fazemos, e , se somos ruins nisso devemos sentir-nos culpados por isso. Assim, a atividade de teste e o projeto de casos de teste são uma admissão de falha, o que promove uma boa dose de culpa. O tédio de testar é apenas uma punição por nossos erros. “ 3

Objetivos da Atividade de Teste de Software O objetivo central deve ser o de maximizar a cobertura dos testes. Detectar a maior quantidade de erros possível de defeitos que não foram apanhados pelas revisões dentro de dados limites de custos e prazos. Se a atividade de teste for conduzida com sucesso, ela descobrirá erros no software. A atividade de teste não pode mostrar a ausência de bugs; ela só pode mostrar se defeitos de software estão presentes. 4

Projeto de Casos de Teste Métodos de Projeto de Casos de Teste oferecem uma abordagem sistemática ao teste.  oferecem um mecanismo que ajuda a garantir a integridade do teste e proporciona a mais alta probabilidade de revelar erros de software 5

Abordagens de Teste para ser eficaz o teste deve ser cuidadosamente desenhado testes irreproduzíveis ou improvisados devem ser evitados resultados devem ser inspecionados e comparados com os resultados esperados desenvolvedores não são as pessoas mais indicadas para testar seu próprio produto testadores independentes são importantes 6

Abordagens de Teste testes são indicadores de qualidade do produto mais do que meios de detecção e correção de erros quanto maior o número de defeitos detectados maior o número de defeitos não detectados a ocorrência de um número anormal de defeitos em uma bateria de testes indica uma provável necessidade de redesenho dos itens testados 6

Abordagens de Teste Teste de Caixa Preta (Black Box) Teste da Caixa Branca (White Box) 6

Abordagens de Teste Teste de Caixa Preta: determina se os requisitos foram total ou parcialmente satisfeitos pelo produto verifica apenas os resultados produzidos, não verifica como ocorre o processamento. demonstram que as funções dos softwares são operacionais, que a entrada é adequadamente aceita e a saída é corretamente produzida; 7

Abordagens de Teste Teste de Caixa Branca: determina defeitos da estrutura interna do programa, através de testes que exercitem suficientemente os possíveis caminhos de execução. São testados os caminhos lógicos através do software, fornecendo-se casos de teste que põem à prova conjuntos específicos de condições e/ou laços. 8

Aproximadamente 1014 caminhos a serem executados Laço <= 20 10

Teste de Caixa Branca Podem ser derivados 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 sua validade. 11

Caixa Branca - Teste de Caminho Básico O método de caminho básico possibilita que o projetista do caso de teste derive uma medida de complexidade lógica de um projeto procedimental e use essa medida como guia para definir um conjunto básico de caminhos de execução. l 12

Caixa Branca - Teste de Caminho Básico GRAFO DE PROGRAMA: uma notação para representar o fluxo de controle. Cada construção estruturada tem um símbolo de grafo correspondente. 13

Cada instrução representa uma ou mais instruções sem ramificações 14

1 2 3 4 6 5 7 8 9 10 11 15

GRAFO DE PROGRAMA Cada círculo é denominado nó representa uma ou mais instruções procedimentais os arcos de fluxo são denominados ramos um ramo deve terminar em um nó as áreas delimitadas pelos ramos e nós são chamadas de regiões nós predicativos são os que contém uma condição 16

Complexidade Ciclomática É uma métrica de software que proporciona uma medida quantitativa da complexidade lógica de um programa. Usado no contexto do método de teste de caminho básico, o valor computado da complexidade ciclomática define o número de caminhos independentes do conjunto básico de um programa Caminho Independente: Qualquer caminho através do programa que introduza pelo menos um novo conjunto de instruções de processamento ou uma nova condição. 17

Complexidade Ciclomática - Caminhos Independentes Como vamos saber o número de caminhos possíveis? 18

Complexidade Ciclomática oferece um limite máximo para o número de testes que deve ser realizado para garantir que todas as instruções sejam executadas pelo menos uma vez. É computada numa das 3 formas seguintes: 1. o número de regiões do gráfico de fluxo 2. V(G) = E-N+2, onde E é o número de ramos do grafo e N o número de nós do grafo de fluxo G 3. V(G) = P+1, onde P é o número de nós predicativos (nós que contém uma condição) contidos no grafo de fluxo G 19

Complexidade Ciclomática 1) o gráfico de fluxo tem 4 regiões 2) V(G)=E-N+2 V(G)= 11 ramos - 9 nós + 2 = 4 3) V(G) = 3 nós predicativos + 1= 4 São preparados casos de teste que forcem a execução de cada caminho observando valores a serem testados e resultados esperados 20

Exercício .Usando o projeto ou o código como base trace um grafo de fluxo correspondente. .Determine a complexidade ciclomática do grafo de fluxo resultante. .Determine um conjunto básico de caminhos linearmente independentes. .Prepare os casos de teste que forcem a execução de cada caminhos no conjunto básico. 21

Teste da Caixa Preta Concentram-se nos requisitos funcionais do software. O teste de caixa preta procura descobrir erros nas seguintes categorias: 1) funções incorretas ou ausentes 2) erros de interface 3) erros nas estruturas de dados ou no acesso a bancos de dados externos 4) erros de desempenho 5) erros de inicialização e término 22

Análise do Valor Limite A análise do valor limite leva a escolha de casos de teste que põem a prova os valores fronteiriços. Casos de teste para entradas válidas: intervalo delimitado pelos valores a e b - os casos de teste devem ser projetados com os valores imediatamente acima e logo abaixo de a e b. série de valores - os casos de teste que ponham a prova valores máximos, mínimos, logo acima e abaixo devem ser testados 25

Análise do Valor Limite Casos de teste para entradas válidas: aplique as diretrizes 1 e 2 às condições de saída. Ex: supondo que uma tabela de temperatura X pressão seja exigida em uma saída de um programa de análise, casos de teste devem ser criados para criar um relatório que produza números máximos e mínimos se as estruturas de dados do programa tiverem prescrito fronteiras (vetor de 100 entradas), certifique-se de projetar um caso de teste para a estrutura de dados em sua fronteira 26

Particionamento de Equivalência Divide o domínio de entrada de um programa em classes de dados a partir das quais os casos de teste podem ser derivados. Procura deduzir uma classe de erros evitando um número maior de testes Em um programa de gestão de pessoal a idade do funcionário varia de 15 a 80. A classe de equivalência são todos os valores inteiros menores do que 15, valores inteiros entre 15 e 80, inclusive, e valores inteiros maiores do que 80. Para cada uma dessas classes qualquer valor tem potencialmente a mesma capacidade de encontrar erros sendo dispensável a execução de vários teses para valores pertencentes a mesma classe. 27

Desenho de classes de equivalência Intervalo válido - uma válida para os valores pertencentes ao intervalo, duas inválidas para os valores maiores e menores que o limite inferior e superior Lista de valores válidos - uma válida para os valores incluídos na lista, uma inválida para todos os outros valores Valor específico - uma válida que inclui o valor, duas inválidas para valores maiores e menores Lógica - uma válida e uma inválida 27

Testes de Comparação Quando é necessário comparar as saídas de diferentes versões de um sistema. Estes testes se aplicam quando: uso de sistemas redundantes para aplicações críticas como controle de aeronaves; comparação de resultados para produtos em evolução. 27

Testes de Sistema de Tempo Real 1. Testes de Tarefas - cada tarefa em um software de tempo real deve ser testada independentemente. Teste de caixa preta e branca devem ser projetados e executados para cada tarefa (revela erros de função). 2. Teste Comportamental- os eventos são categorizados para o teste, cada um dos eventos é testado individualmente o comportamento do sistema executável é examinado para detectar erros conseqüentes dos processamentos associados aos eventos. Quando todas as classes de eventos tiverem sido testadas, os evento serão apresentados de forma aleatória e com freqüência aleatória, detectando erros de comportamento. Posso fazer isto usando ferramentas de simulação, simulando o comportamento de sistemas em tempo real e verificando como ele responde a eventos externos. 27

Testes de Sistema de Tempo Real 3. Teste Inter-tarefas detectam erros de sincronização de tarefas. Tarefas assíncronas que comunicam-se entre si são testadas com diferentes taxas de dados e dados e cargas de processamento para determinar se ocorrerão erros de sincronização inter-tarefas. 4. Teste do Sistema - o software e o hardware são integrados e uma variedade completa de testes de sistema é levado a feito numa tentativa de descobrir erros na interface software/hardware. 27