Testes de SW Aula 12

Sumário Objectivos e Responsáveis Princípios dos Testes Software fácil de testar Desenho de casos de teste Testes Caixa Branca Caminho básico Estrutura de controlo Caixa preta Ambiente, arquitectura e aplicações OO

Objectivos e Responsáveis

Princípios dos Testes

Software fácil de testar

Desenho de casos de teste

Testes

Caixa Branca

Caminho básico

Estrutura de controlo

Caixa preta

Ambiente, arquitectura e aplicações

OO

Objectivos e Responsáveis Descobrir erros Um bom teste tem uma alta probabilidade de detectar erros não descobertos Um teste tem sucesso SE descobrir um erro não detectado Quem faz Engenheiros de SW Testadores Engenheiros de SW especialistas em testes

Descobrir erros

Um bom teste tem uma alta probabilidade de detectar erros não descobertos

Um teste tem sucesso SE descobrir um erro não detectado

Quem faz

Engenheiros de SW

Testadores

Engenheiros de SW especialistas em testes

Princípios Os testes deviam detectar desde erros de código até a satisfação de requisitos Devem ser planificadas Isolar módulos “suspeitos” e testá-los aprofundadamente Começar pelos módulos e terminar no sistema inteiro Não é possível fazer testes exaustivos Realizados por equipas independentes

Os testes deviam detectar desde erros de código até a satisfação de requisitos

Devem ser planificadas

Isolar módulos “suspeitos” e testá-los aprofundadamente

Começar pelos módulos e terminar no sistema inteiro

Não é possível fazer testes exaustivos

Realizados por equipas independentes

Software fácil de testar - características Observabilidade (o que você vê é o que você testa) Saída diferente para cada entrada Estados e variáveis do sistema podem ser consultados durante a execução Estados e variáveis do sistema antigos podem ser consultados (registos de transacção) Todos os factores que afectam os resultados são visíveis Um resultado incorrecto identifica-se com facilidade Os erros internos detectam-se automaticamente O código fonte é acessível

Observabilidade (o que você vê é o que você testa)

Saída diferente para cada entrada

Estados e variáveis do sistema podem ser consultados durante a execução

Estados e variáveis do sistema antigos podem ser consultados (registos de transacção)

Todos os factores que afectam os resultados são visíveis

Um resultado incorrecto identifica-se com facilidade

Os erros internos detectam-se automaticamente

O código fonte é acessível

Controlabilidade (quanto + controlável, + automatizável e optimizável) Todos os resultados possíveis gerados através da combinação de entradas Estados e variáveis do sistema são controláveis pelo programador Formatos de E/S são estruturados e consistentes Os testes podem especificar-se, automatizar-se e reproduzir-se convenientemente Modularidade (controlando o âmbito dos testes, os problemas podem ser isolados) O sistema está construído em módulos independentes Os módulos podem ser testados independentemente Software fácil de testar - características

Controlabilidade (quanto + controlável, + automatizável e optimizável)

Todos os resultados possíveis gerados através da combinação de entradas

Estados e variáveis do sistema são controláveis pelo programador

Formatos de E/S são estruturados e consistentes

Os testes podem especificar-se, automatizar-se e reproduzir-se convenientemente

Modularidade (controlando o âmbito dos testes, os problemas podem ser isolados)

O sistema está construído em módulos independentes

Os módulos podem ser testados independentemente

Simplicidade (há menos que testar) Simplicidade funcional (características mínimas) Simplicidade estrutural (que impede propagação de falhas) Simplicidade do código (selecção de standards, boas práticas de programação) Estabilidade (menos mudanças) Mudanças não frequentes Mudanças controladas Mudanças não invalidam testes O software lida bem com as falhas Software fácil de testar - características

Simplicidade (há menos que testar)

Simplicidade funcional (características mínimas)

Simplicidade estrutural (que impede propagação de falhas)

Simplicidade do código (selecção de standards, boas práticas de programação)

Estabilidade (menos mudanças)

Mudanças não frequentes

Mudanças controladas

Mudanças não invalidam testes

O software lida bem com as falhas

Facilidade de compreensão (+informação, melhores testes) O Desenho foi compreendido Dependências entre componentes internos foi compreendida Mudanças ao desenho foram comunicadas Documentação técnica acessível instantaneamente, está bem organizada, é exacta, específica e detalhada. Operatividade (quanto melhor funcionar, + eficientemente se pode testar) Tem poucos erros Os erros não bloqueiam a execução dos testes O produto evolui em fases Software fácil de testar - características

Facilidade de compreensão (+informação, melhores testes)

O Desenho foi compreendido

Dependências entre componentes internos foi compreendida

Mudanças ao desenho foram comunicadas

Documentação técnica acessível instantaneamente, está bem organizada, é exacta, específica e detalhada.

Operatividade (quanto melhor funcionar, + eficientemente se pode testar)

Tem poucos erros

Os erros não bloqueiam a execução dos testes

O produto evolui em fases

Desenho de casos de teste Caixa preta Testes sobre as interfaces do Produto de SW Caixa branca Testes sobre os detalhes dos procedimentos de cada função Conhecemos a função específica para a qual foi desenhado o produto. Podemos levar a cabo Testes que demonstram que cada função está completamente operacional. Conhecemos o funcionamento do produto. Podemos desenvolver testes que asseguram que “todas as peças se encaixam”. Ou seja, que a operação interna se ajusta às especificações e que todos os componentes internos foram comprovados de maneira adequada.

Caixa preta

Testes sobre as interfaces do Produto de SW

Caixa branca

Testes sobre os detalhes dos procedimentos de cada função

casos de teste de Caixa Branca garantem o exercício de: Todos os caminhos independentes são utilizados Todas as vertentes falsas e verdadeiras das decisões lógicas Todos os ciclos nos seus limites Todas as estruturas internas de dados Permitem ver Erros lógicos e supostos incorrectos Fluxo lógico real dum programa Erros tipográficos Porém os testes exaustivos apresentam problemas logísticos tornando estes testes impossíveis para grandes sistemas de SW Devemos, então, seleccionar quais são os caminhos lógicos mais importantes

garantem o exercício de:

Todos os caminhos independentes são utilizados

Todas as vertentes falsas e verdadeiras das decisões lógicas

Todos os ciclos nos seus limites

Todas as estruturas internas de dados

Permitem ver

Erros lógicos e supostos incorrectos

Fluxo lógico real dum programa

Erros tipográficos

Porém

os testes exaustivos apresentam problemas logísticos tornando estes testes impossíveis para grandes sistemas de SW

Devemos, então, seleccionar quais são os caminhos lógicos mais importantes

Teste do caminho básico É uma técnica de teste de caixa branca Medida da complexidade lógica Mede o nº de caminhos independentes Os casos de teste obtidos por este método garantem que cada instrução seja executada pelo menos 1 vez Pode tornar-se impossível, se o sistema for muito grande..

É uma técnica de teste de caixa branca

Medida da complexidade lógica

Mede o nº de caminhos independentes

Os casos de teste obtidos por este método garantem que cada instrução seja executada pelo menos 1 vez

Pode tornar-se impossível, se o sistema for muito grande..

Testes da estrutura de controlo Auxiliam as técnicas de Testes de Caixa Branca Teste da condição Teste de fluxos de dados caminhos de teste segundo a localização das definições e usos das variáveis Testes de ciclos Passar por alto Passar 1 vez Passar 2 vezes Fazer m passos com m<n exemplo: se o ciclo executa 10 laços, testamos até o laço 3.. Fazer n-1, n e n+1 exemplo: se o ciclo executa 10 laços, testamos 9, 10 e forçamos 11 laços ..

Auxiliam as técnicas de Testes de Caixa Branca

Teste da condição

Teste de fluxos de dados

caminhos de teste segundo a localização das definições e usos das variáveis

Testes de ciclos

Passar por alto

Passar 1 vez

Passar 2 vezes

Fazer m passos com m<n

exemplo: se o ciclo executa 10 laços, testamos até o laço 3..

Fazer n-1, n e n+1

exemplo: se o ciclo executa 10 laços, testamos 9, 10 e forçamos 11 laços ..

casos de testes de Caixa Preta - várias técnicas Métodos baseados em grafos Entender os objectos de dados modelados e as suas relações Definir uma série de testes que verifiquem “que todos os objectos possuem as relações esperadas entre eles” Criar um grafo uma colecção de nós que representa os objectos Método da Partição equivalente Método da Análise de valores limites Testes de comparação Testes da tábua ortogonal Domínos de problemas pequenos Mas que exigem muitas provas exaustivas

Métodos baseados em grafos

Entender os objectos de dados modelados e as suas relações

Definir uma série de testes que verifiquem “que todos os objectos possuem as relações esperadas entre eles”

Criar um grafo

uma colecção de nós que representa os objectos

Método da Partição equivalente

Método da Análise de valores limites

Testes de comparação

Testes da tábua ortogonal

Domínos de problemas pequenos

Mas que exigem muitas provas exaustivas

E ainda: Testes de ambientes, arquitecturas e aplicações Testes de interfaces Testes de arquitectura cliente/servidor Testes da documentação e facilidades de ajuda Testes de sistemas a tempo-real

Testes de interfaces

Testes de arquitectura cliente/servidor

Testes da documentação e facilidades de ajuda

Testes de sistemas a tempo-real

próxima aula teórica

Testes OO Processos de SW OO: quando concluir uma iteração de AOO, DOO e Testes OO? Testes OO para a Lacertae SW

Processos de SW OO:

quando concluir uma iteração de AOO, DOO e Testes OO?

Testes OO para a Lacertae SW