Verificação, Validação e Testes: Teste de Software

(1)

Grupo de Engenharia de Software Experimental http://ese.cos.ufrj.br

CEDESC

Curso de Especialização em Desenvolvimento de Software

PETROBRAS

Guilherme Horta Travassos

www.cos.ufrj.br/~ght

Verificação, Validação e Testes:

Teste de Software

Roteiro Roteiro

Módulo I: Conceitos e Definições de Teste de Software

Módulo II:Técnicas de Teste de Software

Módulo III: Estratégias para Projeto e Execução dos Testes

Módulo IV: Planejamento e Controle de Testes

de Software

(2)

http://ese.cos.ufrj.br ^CopyrightG.H. Travassos 2010

M M ódulo I ó dulo I

Conceitos e Definições de Teste de Software

M

Mó ódulo I: Roteiro dulo I: Roteiro

Conceitos Básicos de Teste de Software em Geral Elementos do Teste de Software

Mitos associados às Atividades de Teste de Software

Níveis de Teste

Desenvolvimento x Teste de Software

Testes de Software em Normas e Modelos de

Maturidade de Processo

(3)

Definições

Garantia de Qualidade de Software

• Verificação:

Assegurar consistência, completude e corretude do produto em cada fase e entre fases consecutivas do ciclo de vida do software.

“Estamos construindo corretamente o produto?”.

• Validação:

Assegurar que o produto final corresponde aos requisitos do software.

“Estamos construindo o produto correto?”.

• Teste:

Examina o comportamento do produto através de sua execução.

Definições

Falta (Fault)

:

É inserida no software quando um desenvolvedor comete algum equívoco. Um equívoco pode causar várias faltas ao mesmo tempo que vários enganos pode causar uma falta idêntica.

Falha (Failure)

:

Representa um comportamento incorreto apresentado por um software em conseqüência de uma falta.

Erro (Error)

:

Representa o quanto um resultado é incorreto.

Defeito (Defect)

:

Termo genérico para falta, falha ou erro..

IEEE 610.12, 1990. A Glossary of Software Engineering Terminologyin Schach, S.R. (2008). Introduction to Object-Oriented Software Engineering. McGraw-Hill

(4)

Teste e Depura Teste e Depuraç ção ão

Teste:

• Processo de executar um software ou sistema com o objetivo de revelar a presença de falhas; ou, falhando nesse objetivo, aumentar a confiança sobre o software

Depuração:

• é uma conseqüência não previsível do teste.

Após revelada a presença do erro, o defeito deve ser encontrado e corrigido

Depuração não é teste!

Elementos do Teste de Software Elementos do Teste de Software

Caso de Teste:

• Descreve uma condição particular a ser testada.

Composto por valores de entrada, restrições para a sua execução e um resultado ou comportamento esperado.

Procedimento (Roteiro) de Teste:

• Descreve os passos necessários para a execução de um ou um grupo de casos de teste

Critérios de Cobertura dos Testes:

• Permitem a identificação de partes do programa que devem ser executadas para garantir a qualidade do software e indicar quando o mesmo foi suficientemente testado.

A Cobertura dos Testes determina o percentual de elementos testados em um programa.

(5)

Elementos do Teste de Software Elementos do Teste de Software

Rodada (Bateria) de Teste:

• Consiste na execução de todos os procedimentos de teste para uma versão do produto em um determinado ambiente de teste

Uma nova rodada de teste deve ser executada caso o critério de aceitação do produto não tenha sido atingido

Incidentes de Teste:

• Qualquer evento ou comportamento diferenciado que ocorra durante a execução dos testes que requer futura investigação

Não há garantia que todo incidente seja uma falha, pois ainda precisa ser analisado

Defeitos no Desenvolvimento Defeitos no Desenvolvimento

de Software de Software

Quanto antes a presença do defeito for revelada, menor o custo de correção do defeito e maior a probabilidade de corrigi-lo corretamente

• Principal causa:

Tradução incorreta de informações

• Solução:

Introduzir atividades de VV&T ao longo de todo o ciclo de desenvolvimento

(6)

Mitos Associados a Testes e Mitos Associados a Testes e

Requisitos (1) Requisitos (1)

Mito:

• “Não é possível testar até que o sistema exista...”

Fatos:

• Testar é muito mais do que apenas “ver o que vai acontecer”

• E muito mais que apenas executar casos de teste!

• Documentos de requisitos podem e devem ser testados em relação aos objetivos do negócio ou projeto para assegurar completude e correção

Mitos Associados a Testes e Mitos Associados a Testes e

Requisitos (2) Requisitos (2)

Mito:

• “Desenvolvedores devem pensar nos requisitos apenas no início do desenvolvimento, e se preocupar com testes apenas no final...”

Fatos:

• Ter os testadores envolvidos durante a análise de requisitos é uma das melhores formas de se assegurar requisitos de boa qualidade

• Trocas tardias nos requisitos causam impacto nos testes

• Ter os usuários envolvidos nos requisitos e nos testes é fundamental!

(7)

Mitos Associados a Testes e Mitos Associados a Testes e

Requisitos (3) Requisitos (3)

Mito:

• “Requisitos são utilizados no teste, mas não o contrário...”

Fatos:

• Você não testa requisitos, mas testa a partir deles!

• É fácil escrever requisitos pouco vagos ou ambíguos, que parecem estar ok. Quando bons testadores observam a especificação de requisitos, eles aconselham casos de teste específicos para acertar os requisitos vagos, ambíguos ou não muito explícitos.

• Boa engenharia de requisitos produz melhores testes;

boa análise de testes melhora os requisitos!

Mitos Associados a Testes e Mitos Associados a Testes e

Requisitos (4) Requisitos (4)

Mito:

• “Se escrever testes é difícil, isto é somente um problema dos testadores...”

Fatos:

• Nem todos os requisitos são criados de acordo com a mesma perspectiva do testador. Para alguns dos requisitos fica fácil definir o teste, para outros um verdadeiro pesadelo!

• Especificar requisitos não funcionais testáveis tais como usabilidade ou desempenho é difícil

• Frases como “fácil de usar”, “interface amigável”,

“muito confiável” ou “desempenho aceitável” não representam especificação de requisitos!

(8)

Mitos Associados a Testes e Mitos Associados a Testes e

Requisitos (5) Requisitos (5)

Mito:

• “Não se preocupe, pequenas modificações nos requisitos não afetarão os testes…”

Fatos:

• Uma modificação aparentemente pequena nos requisitos pode trazer grande impacto para os testes

• Você deve testar todas as modificações para confirmar que o sistema está executando corretamente. É possível que testes de regressão sejam necessários

• O esforço do teste face a modificação vai depender dos riscos associados à modificação e dos impactos conhecidos (e desconhecidos!) no sistema

Mitos Associados a Testes e Mitos Associados a Testes e

Requisitos (6) Requisitos (6)

Mito:

• “Os testadores não precisam dos requisitos…”

Fatos:

• O sistema deve apoiar o negócio a atingir um objetivo, então o que o sistema realmente faz deve ser comparado com este objetivo

• Uma especificação de requisitos representa o oráculo para o teste!

• Sim, testadores precisam dos requisitos, caso contrário, você poderia argumentar que o que vem sendo executado não é realmente um teste!

(9)

Mitos Associados a Testes e Mitos Associados a Testes e

Requisitos (7) Requisitos (7)

Mito:

• “Os testadores não podem testar sem os requisitos…”

Fatos:

• Este é também um mal entendido comum

• Algumas vezes modificações são realizadas nos sistemas onde requisitos são inadequados ou não existentes. Isto faz o teste ser mais difícil, mas não é possível dizer que não pode ser feito

Aplicar teste exploratório pode ser uma saída

Objetivo dos Testes de Software Objetivo dos Testes de Software

Refutar a assertiva de que o produto está correto

• Determinar entradas que façam as saídas obtidas diferirem das saídas esperadas de acordo com a especificação (busca de um contra-exemplo)

• É um processo destrutivo, sob o ponto de vista psicológico, contrariamente às demais fases da Engenharia de Software, onde constrói-se um produto

(10)

Caracter

Caracterí ísticas dos Testes de sticas dos Testes de Software

Software

Uma das atividades mais onerosas do desenvolvimento de software

Último recurso para avaliação do produto antes de sua entrega ao usuário final

Atividade essencial para ascensão ao nível 3 do CMMI e Nível D do MPS

Atividade relevante para avaliação de produtos de software

(ISO 9126, ISO 14598-5)

Princ

Princí ípios de Teste de Software pios de Teste de Software

Os testes devem ser rastreáveis aos requisitos do usuário

• devem ser realizados para testar os requisitos do usuário

Devem ser completamente planejados antes de seu início.

• O planejamento é primordial para sua execução

O princípio de Paretto se aplica:

• 80% de todos os erros encontrados a partir das falhas reveladas estarão concentrados em 20% dos componentes do software

(11)

Princ

Princí ípios de Teste de Software pios de Teste de Software

Devem ser aplicados inicialmente em pequena escala e depois expandidos

Não é possível aplicá-los exaustivamente

Para aumentar sua eficácia, deve ser executado por equipes independentes (quem não desenvolveu o software)

Para evitar viés na execução, os testadores devem ser diferentes daqueles que planejaram os testes

Teste de Software Teste de Software

O que identifica um bom teste ?

• Possui alta probabilidade de revelar falhas

• Não é redundante

• É abrangente o suficiente

• Possui um nível adequado de complexidade

(12)

Testabilidade

Testabilidade de Software de Software

Simplesmente tenta mostrar a facilidade com que um software pode ser testado

• Operação

quanto melhor funciona, mais eficientemente pode ser testado

• Observação

o que você vê é o que você testa

• Controle

quanto melhor podemos controlar o software, mais podemos automatizar e melhorar o teste

Testabilidade

Testabilidade de Software de Software

• Decomposição

Controlando o escopo do teste, podemos mais rapidamente isolar os problemas e executar re-teste adequado

• Simplicidade

Quanto menos existe para se testar, mais rapidamente podemos testar o software

• Estabilidade

Quanto menos modificações, menos problemas para testar

• Compreensão

quanto mais informação tivermos, mais adequado será o teste

(13)

Teste de Software Teste de Software

Software é de alta Qualidade?

• Não ocorrência de falha:

Teste é de baixa Qualidade?

OU

Teste de Software Teste de Software

Defeitos e erros "emboscados" no software e não revelados

Falhas a se manifestarem na utilização pelos usuários e defeitos corrigidos durante a manutenção.

CUSTOS ALTÍSSIMOS!

(14)

Teste de Software Teste de Software

Custos resultantes de testes insuficientes:

US$ 22.2 a 59.5 bi

(NIST, National Institute of Standards and Technology ,Maio 2002)

Atividade que tipicamente envolve:

• Execução do software com entradas representativas para as futuras condições de operação

• Comparação entre saídas produzidas e esperadas

• Comparação entre estados resultantes e esperados

• Mensuração de características de execução (memória e tempo consumidos,etc.)

Teste de Software Teste de Software

Se falhas graves se manifestam

modificação do projeto, se erros são encontrados com regularidade

Qualidade e confiabilidade sob suspeita

NOVOS TESTES!

torna-se necessária a

colocam

revelando a necessidade de

(15)

Teste de Software Teste de Software

Defeitos de fácil correção indicam que as funções aparentemente funcionam bem.

Qualidade e confiabilidade aceitáveis, ou testes inadequados para revelar a ocorrência

de falhas graves?

Teste de Software Teste de Software

Estratégias para Teste

• Unidade

• Integração

• Sistema

• Re-Teste Regressão “Fumaça”

• Aceitação

• Instalação

Unidade Unidade

Integra Integraççãoão Alta ordem Alta ordem

código Projeto

Requisitos

(16)

Teste de Software Teste de Software

Unidade Integração

Perspectiva dos

projetistas/desenvolvedores

Funcional Não-Funcional

Aceitação Instalação

Perspectiva do Cliente/Usuário

Infra

Infra -Estrutura - Estrutura para para Teste Teste

Driver

Componente a ser testado

Stub Stub

Resultados

Casos de Teste

Interface Estruturas de Dados Locais

Condições Limites Caminhos Independentes Caminhos de tratamento de erros

(17)

Teste de Unidade Teste de Unidade

É a fase do processo de teste em que se testam as menores unidades de software desenvolvidas

• O universo alvo desse tipo de teste são os métodos dos objetos ou mesmo pequenos trechos de código

Objetivo:

• encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo Existem situações em que você não terá os recursos para

realizar o teste completo das unidades.

• Selecione os módulos críticos e aqueles com alta complexidade e apenas teste estes módulos

• Utilize inspeções de código

Teste de Integra Teste de Integra ção ç ão

"Se todos os módulos funcionam individualmente (analisado através do teste de unidade), por que se tem dúvida de que eles funcionarão quando colocados juntos?“

O problema é exatamente "colocá-los juntos" – tendo uma interface.

Teste de Integração

• Fase destinada à construção da estrutura do programa, realizando- se, ao mesmo tempo, testes para descobrir erros associados a interface

• A partir dos módulos testados no nível de unidade, construir a estrutura de programa que foi determinada pelo projeto

• Além disso, encontrar falhas provenientes da integração interna dos componentes de um sistema

• Tipos de falhas: envio e recebimento de dados

Ex: Por exemplo, um objeto A pode estar aguardando o retorno de um valor X ao executar um método do objeto B, porém este objeto B pode retornar um valor Y, desta forma gerando uma falha

(18)

Teste de Integra Teste de Integra ção ç ão

Aplicar a abordagem “big bang” para integração é uma estratégia ingênua que está fadada ao fracasso.

• Teste de integração deve ser conduzido de forma incremental e organizada!

Top-Down

• Quando você desenvolve um cronograma detalhado para o projeto você tem que considerar a maneira na qual a integração de componentes ocorrerá de forma que os componentes estejam disponíveis quando necessários

Bottom-up

• Integração “bottom-up” elimina a necessidade de “stubs”

complexos

Teste de Sistema Teste de Sistema

Objetivo:

• executar o sistema sob ponto de vista de seu usuário final, varrendo as funcionalidades em busca de falhas

Testes executados em condições similares (de ambiente,

interfaces sistêmicas e massa de dados) àquelas que um usuário utilizará no seu dia-a-dia

Um sistema divide-se em características Funcionais e Não- Funcionais:

• Funcional:

Ignora a estrutura do sistema Foco na funcionalidade

• Não-Funcional

Considera as características de qualidade do sistema: Usabilidade, Portabilidade, Recuperabilidade, Segurança, Eficiência, ...

Sistema = Funcional + Não-Funcional

(19)

Teste de Sistema Teste de Sistema

Tipos específicos de Teste de Sistema:

• Recuperação

força o software a falhar numa variedade de situações e verifica a capacidade de recuperação do produto

• Segurança

verifica se os mecanismos de proteção construídos para o sistema irão de fato protegê-lo de alguma utilização ou intrusão imprópria.

• Stress

executa o sistema de forma a exigir recursos em quantidade, freqüência ou volume anormais

• Desempenho

avalia o desempenho do software quando integrado ao sistema.

Normalmente está associado ao teste de stress

Estrat

Estraté égias para Re gias para Re- - Teste Teste

Podem ocorrer para qualquer estratégia de teste, em caso de mudanças no software no planejamento dos testes

Dois tipos:

• Regressão

Teste de regressão é uma estratégia importante para redução de

“efeitos colaterais”.

Consiste em se aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema.

Execute testes de regressão toda vez que uma modificação maior é realizada no software (incluindo a integração de novos módulos)

Efetue a gerência de configuração

• “Fumaça” (smoke testing)

Teste fumaça pode ser caracterizado como estratégia de integração incremental.

O software é reconstruído (com novos componentes incorporados) e exercitado diariamente.

(20)

Teste de Aceita Teste de Aceitaç ção ão

Assim como os outros tipos de teste, validação tenta descobrir erros, mas o foco está nos requisitos - nas características que estarão imediatamente aparentes para o usuário final

Os testes são realizados, geralmente, por um grupo restrito de usuários finais do sistema

Teste formal conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação e para permitir ao cliente determinar se aceita ou não o sistema.

• Critérios para Teste de Aceitação

1. A funcionalidade (caso de uso) ou características de desempenho estão de acordo com o especificado e são aceitas 2. Uma variação da especificação é descoberta e uma lista de

discrepâncias (deficiências) é criada

Teste de Aceita Teste de Aceitaç ção ão

Revisão da Configuração

• Assegura que todos os elementos da configuração de software foram propriamente desenvolvidos, estão catalogados e possuem o nível de detalhe suficiente para serem utilizados durante o ciclo de vida do software

Algumas vezes identificada como auditoria.

Teste Alfa e Beta

• Alfa: executado na instalação do desenvolvedor pelo cliente

• Beta: executado na instalação de um ou mais clientes pelo usuário final do software

(21)

Teste de Instala Teste de Instalaç ção ão

Consiste em instalar o sistema nos locais em que estão os usuários

• Dispensado no caso do teste de aceitação ter sido executado no ambiente do usuário

Focam:

• A integridade do sistema instalado; e

• A verificação quanto a se alguma característica funcional ou não funcional foi afetada pelas condições do local de operação

Desenvolvimento x Testes Desenvolvimento x Testes

Requisitos do Sistema

Requisitos do Software

Modelo de Projeto

Código

Teste de Aceitação

Teste de Sistema

Teste de Integração

Teste de Unidade

Projeto dos Testes Execução dos testes

(22)

Teste de Software em Normas e Teste de Software em Normas e Modelos de Maturidade de Processos Modelos de Maturidade de Processos

ISO 12207

• Norma para definição de processos de ciclo de vida de software

Objetivo é auxiliar na definição de processos de software organizacionais

ISO 15504 – SPICE

• Padrão internacional para Avaliação de Processo de Software inspirada pelo Software CMM e ISO 9001

Objetivo de harmonizar diferentes modelos (Software CMM, CMMI, ISO 9001, ISO 12207 e Bootstrap)

CMMI e MPS

• Modelos para estabelecimento de padrão de qualidade para processos de software

Teste de Software Teste de Software

Recomendações:

• Convide os testadores a participar das revisões dos requisitos e inspeções

• Comece o planejamento do teste em paralelo com a análise de requisitos

• Inclua sugestões de condições de teste e casos de teste para utilizar como exemplos na especificação de requisitos

• Inclua no documento de requisitos qualquer caso específico que vier a mente quando estiver analisando os requisitos

• Utilize cenários de negócios e casos de uso para dar exemplos específicos de como o sistema deveria funcionar

• Identifique critérios mensuráveis para ambos os tipos de requisitos (funcionais e não funcionais) ...

(23)

Mó M ódulo II dulo II

Técnicas de Teste de Software

M

Mó ódulo II: Roteiro dulo II: Roteiro

Projeto de Casos de Teste Critérios de Teste

Técnicas de Teste:

• Funcional x Estrutural x Baseada em Erros

Exercícios de Fixação

(24)

Projeto de Casos de Teste Projeto de Casos de Teste

Projeto de teste pode ser tão difícil quanto o projeto do próprio produto a ser testado

Poucos programadores/analistas gostam de teste; menos ainda de projeto de casos de teste Projeto de teste é um dos melhores mecanismos

para prevenção de defeitos

O projeto de casos de teste é tão eficaz em identificar erros quanto a execução dos casos de teste projetados

• Funciona como uma forma de revisão!

Projeto

Projeto de Casos de Casos de Teste de Teste

Esteja certo que você projeta testes para executar todo caminho de tratamento de erro

• Senão, o caminho pode falhar quando ativado, revelando uma situação nem sempre agradável do sistema

Existem algumas situações nas quais você não terá todos os recursos para realizar um teste completo das unidades

• Selecione os componentes mais críticos e aqueles com alta complexidade ciclomática e teste inicialmente estes

(25)

Crit

Crité érios de Teste rios de Teste

Dados um programa Pe um conjunto de casos de teste T, definem-se:

• Critério de Seleção de Casos de Teste:

procedimento para escolher casos de teste para o teste de P.

• Critério de Adequação de Casos de Teste:

predicado para avaliar T no teste de P;

Existe uma forte correspondência entre critérios de seleção e de adequação de casos de teste

• Dado um critério de adequação C, existe um critério de seleção CSque estabelece: selecione Ttal que Tseja adequado a C

• Dado um critério de seleção CS, existe um critério de adequação C que estabelece: T é adequado se foi selecionado de acordo com CS

Critério de Seleção de Casos de Teste

É um método de escolha de casos de teste

• se obedecido, gera um conjunto de casos de teste capaz de identificar falhas causadas por uma determinada categoria de erros

Um critério de seleção de casos de teste deve ser

• válido:

acusa falhas sempre que existam erros no artefato sendo testado

• confiável:

as falhas encontradas são indiferentes à escolha dos dados e das ações desde que satisfaçam as condições dos casos de teste

• completo:

segundo um padrão de completude

• viável:

Deve possuir um custo de aplicação razoável

(26)

Critério de Adequação de Casos de Testes

Define quais propriedades precisam ser testadas para garantir inexistência de erros

Como é impossível garantir inexistência de erros, o

conceito é utilizado, na prática, para definir uma qualidade mínima que será validada pelo teste

Objetivo:

• ... obter, de maneira sistemática um conjunto T de casos de teste efetivo quanto à meta principal de teste – revelar falhas no programa

Propriedades:

• i) incluir todos os desvios de fluxo de execução

• ii) incluir pelo menos um uso de todo resultado computacional

• iii) T mínimo e finito

T é C-adequado ⇔ todo elemento requerido por C é exercitado por pelo menos um t, t∈T

T

Té écnicas para Teste de Software cnicas para Teste de Software

Técnicas:

• Funcional (ou caixa preta/caixa fechada)

• Estrutural (ou caixa branca/caixa aberta)

• Baseada em erros

A questão não está em qual delas utilizar e sim

como combiná-las de forma a maximizar os

benefícios das atividades de teste!

(27)

Té T écnica Funcional cnica Funcional

Baseia-se na especificação do software para derivar os requisitos de teste

Aborda o software de um ponto de vista macroscópico

Envolve dois passos principais:

• identificar as funções que o software deve realizar (especificação dos requisitos, casos de uso)

• criar casos de teste capazes de verificar se essas funções estão sendo executadas corretamente

T

Té écnica Funcional cnica Funcional

Problema:

• Dificuldade em quantificar a atividade de teste - não se pode garantir que partes essenciais ou críticas do software foram executadas

Critérios da Técnica Funcional:

• Particionamento em Classes de Equivalência

• Análise do Valor Limite

• Grafo de Causa-Efeito

(28)

T

Té écnica Funcional cnica Funcional

Particionamento em Classes de Equivalência

• Divide o domínio de entrada do programa em classes de dados (classes de equivalências)

os dados de teste são derivados a partir das classes de equivalência

Eventualmente, pode se considerar o domínio de saída como referência (ex. relatórios)

T

Té écnica Funcional cnica Funcional

Particionamento em Classes de Equivalência

• Dois Passos:

Identificar classes de equivalência (é um processo heurístico)

condição de entrada válidas e inválidas

Definir os casos de teste

enumeram-se as classes de equivalência casos de teste para as classes válidas casos de teste para as classes inválidas

(29)

T

Té écnica cnica Funcional Funcional

Particionamento em Classes de Equivalência

• Método “caixa-preta” que divide o domínio de entrada de um sistema em classes (categorias) de dados das quais casos de teste podem ser derivados

• Força a definição de um caso de teste que revela categorias de erros, desta forma reduzindo o número total de casos de teste que devem ser desenvolvidos

• Baseado na avaliação de classes de equivalência para uma condição de entrada

• “Se um conjunto de objetos podem ser ligados por relacionamentos que são simétricos, transitivos e reflexivos, uma classe de equivalência está presente.”

T

Té écnica cnica Funcional Funcional

Particionamento em Classes de Equivalência

• Uma classe de equivalência representa um conjunto de estados válidos e inválidos para uma condição de entrada.

Tipicamente uma condição de entrada pode ser um valor numérico específico, uma faixa de valores, um conjunto de valores relacionados, ou uma condição lógica.

• Diretrizes:

Se uma condição de entrada especifica uma faixa de valores ou requer um valor específico, uma classe de equivalência válida e duas inválidas são definidas;

Se uma condição de entrada especifica um membro de um conjunto ou é lógica, uma classe de equivalência válida e uma inválida são definidas

(30)

Classe de Equivalência: Exemplo Classe de Equivalência: Exemplo

Especificação do programa Identifier:

O programa deve determinar se um identificador é válido ou não em Silly Pascal (uma estranha variante do Pascal). Um identificador válido deve começar com uma letra e conter apenas letras ou dígitos. Além disso, deve ter no mínimo 1 caractere e no máximo 6 caracteres de comprimento.

Exemplo:

abc12 (válido);

cont*1 (inválido);

1soma (inválido);

a123456 (inválido)

BARBOSA, E.; MALDONADO, J.C.; VINCENZI, A.M.R.; DELAMARO, M.E; SOUZA, S.R.S. e JINO, M.. Introdução ao Teste de Software. XIV Simpósio Brasileiro de Engenharia de Software. 2000 (disponivel em

http://safedevel.icmc.usp.br/coweb/checkout.php?wikipage_id=72.4&filename=transp-Ellen.pdf, último acesso em 07/03/2007)

Classes de equivalência

Tamanho t do identificador

Condições de Entrada Classes Válidas Classes Inválidas 1 ≤t ≤6

(1)

Primeiro caractere c é uma letra

Só contém caracteres válidos

t >6 (2)

Sim (3)

Não (4)

Sim (5)

Não (6)

Exemplo de Conjunto de Casos de Teste

T₀= {(a1,Válido), (2B3, Inválido), (Z-12, Inválido), (A1b2C3d, Inválido)}

Classe de Equivalência: Exemplo

(31)

T

Té écnica cnica Funcional Funcional

Análise do Valor Limite

• Por razões não completamente identificadas, um grande número de erros tende a ocorrer nos limites do domínio de entrada invés de no “centro”

• Análise do Valor Limite é uma técnica de teste que explora os limites dos valores para preparar os casos de teste

• Está técnica complementa o particionamento em classes de equivalência

T

Té écnica cnica Funcional Funcional

Análise do Valor Limite - Diretrizes

• Se uma condição de entrada especifica uma faixa de valores limitadas em a e b, casos de teste devem ser projetados com valores a e b e imediatamente acima e abaixo de a e b;

• Se uma condição especifica um número de valores, casos de teste deveriam ser desenvolvidos para exercitar os números mínimo e máximo. Valores imediatamente acima e abaixo do mínimo e máximo são também testados

Ex: A={1..10}; Casos de Teste => {1, 10, 0,11}

• Aplique as diretrizes 1 e 2 para as condições de saída. Por exemplo, assuma que uma tabela de temperatura x pressão é necessária como saída de um programa de análise de engenharia. Casos de teste deveriam ser projetados para criar um relatório de saída que produza o máximo (e mínimo) número possível de entradas na tabela;

• Se uma estrutura de dados interna do programa tem identificados seus limites (ex. Um vetor com 100 posições), esteja certo de projetar um caso de teste para exercitar a estrutura de dados em seu limite

(32)

Análise do Valor Limite: Exemplo

Consideremos a seguinte situação:

"... o cálculo do desconto por dependente é feito da seguinte forma:

a entrada é a idade do dependente que deve estar restrita ao intervalo [0..24]. Para dependentes até 12 anos (inclusive) o desconto é de 15%. Entre 13 e 18 (inclusive) o desconto é de 12%. Dos 19 aos 21 (inclusive) o desconto é de 5% e dos 22 aos 24 de 3%..."

Aplicando o teste de valor limite convencional serão obtidos casos de teste semelhantes a este:

• {-1,0,12,13,18,19,21,22,24,25} incluindo valores fora da faixa.

T

Té écnica cnica Funcional Funcional

Grafo de Causa-Efeito

• Técnica para identificação de casos de teste que explora as condições lógicas e as ações correspondentes.

• Basicamente, 4 passos devem ser executados:

Para cada módulo, Causas (condições de entrada) e efeitos (ações realizadas às diferentes condições de entrada) são relacionados, atribuindo-se um identificador para cada um.

Em seguida, um grafo de causa-efeito (árvore de decisão) é desenhado.

Neste ponto, transforma-se o grafo numa tabela de decisão.

As regras da tabela de decisão são, então, convertidas em casos de teste.

(33)

Grafo Causa

Grafo Causa- - Efeito: Exemplo Efeito: Exemplo

Causa: valor compra > 80 ^ #produtos < 3 Efeito: frete grátis

Valor compra

#produtos

Cobrar Frete Frete Grátis

>80

<=80

< 3

>=3

Valor Compra >80 >80 <=80

#Produtos <3 >=3 --

Cobrar Frete V V

Frete Grátis V

Árvore de Decisão

Tabela de Decisão Causa

Efeito

T

T écnica é cnica Estrutural Estrutural

É baseada no conhecimento da estrutura interna da implementação

Teste dos detalhes procedimentais

A maioria dos critérios dessa técnica utiliza uma

representação de programa conhecida como

grafo de programa ou grafo de fluxo de controle

(34)

/* 01 */ {

/* 01 */ char achar;

/* 01 */ int length, valid_id;

/* 01 */ length = 0;

/* 01 */ printf ("Digite um possível identificador\n");

/* 01 */ printf ("seguido por <ENTER>: ");

/* 01 */ achar = fgetc (stdin);

/* 01 */ valid_id = valid_starter (achar);

/* 01 */ if (valid_id)

/* 02 */ length = 1;

/* 03 */ achar = fgetc (stdin);

/* 04 */ while (achar != '\n') /* 05 */ {

/* 05 */ if (!(valid_follower (achar)))

/* 06 */ valid_id = 0;

/* 07 */ length++;

/* 07 */ achar = fgetc (stdin);

/* 07 */ }

/* 08 */ if (valid_id && (length >= 1) && (length < 6) ) /* 09 */ printf ("Valido\n");

/* 10 */ else

/* 10 */ printf ("Invalido\n");

/* 11 */ }

Programa Identifier.c

BARBOSA, E.; MALDONADO, J.C.; VINCENZI, A.M.R.; DELAMARO, M.E; SOUZA, S.R.S. e JINO, M.. Introdução ao Teste de Software. XIV Simpósio Brasileiro de Engenharia de Software. 2000 (disponivel em

http://safedevel.icmc.usp.br/coweb/checkout.php?wikipage_id=72.4&filename=transp-Ellen.pdf, último acesso em 07/03/2007)

Té T écnica Estrutural (Grafo de Programa) cnica Estrutural (Grafo de Programa)

Detalhes considerados:

• nó

• arco

• caminho:

simples completo livre de laço

• fluxo de controle

Grafo de Programa do identifier.c Gerado pela View-Graph (USP-SC)

(35)

Té T écnica Estrutural (Grafo de Programa) cnica Estrutural (Grafo de Programa)

Nós:

• blocos “indivisíveis”

não existe desvio para o meio do bloco

uma vez que o primeiro comando do bloco é executado, os demais comandos são executados seqüencialmente

Arestas ou Arcos:

• representam o fluxo de controle entre os nós

T

T écnica Estrutural é cnica Estrutural

Critérios da Técnica Estrutural:

Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger - Prentice Hall- Cap. 08

(36)

T

T écnica Estrutural é cnica Estrutural

Critérios de Fluxo de Controle

• Todos-Nós:

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

• Todos-Arcos:

arcos primitivos:

<1,2>,<1,3>,<5,6>,<5,7>,

<8,9>,<8,10>

• Todos-Caminhos

Grafo de Programa do identifier.c Gerado pela View-Graph (USP-SC)

T

Té écnica Baseada em Erros cnica Baseada em Erros

Os requisitos de teste são derivados a partir dos erros mais freqüentes cometidos durante o processo de desenvolvimento do software

Critérios da Técnica Baseada em Erros:

• Semeadura de Erros

• Análise de Mutantes (teste de unidade)

• Mutação de Interface (teste de integração)

(37)

P Q

T

P(t) ≠ Q(t)

t ∈T

An

Aná álise de Mutantes lise de Mutantes

Garantir a ausência de determinados tipos de defeitos Considerando todos os programas Q, é possível provar

a correção de P

É impraticável executar e comparar todos os programas Q Estabelece-se então uma vizinhança Φ(P) que contém

apenas um conjunto finito de programas

Esses programas contêm pequenos desvios sintáticos que representam defeitos simples

An

Aná álise de Mutantes lise de Mutantes

Hipótese do Programador Competente

Programadores experientes escrevem programas corretos ou muito próximos do correto

Efeito de Acoplamento

Casos de teste capazes de revelar erros simples

são tão sensíveis que, implicitamente, também

são capazes de revelar erros mais complexos

(38)

An

Aná álise de Mutantes lise de Mutantes

Os operadores de mutação determinam o tipo de alteração sintática que deve ser feita para a criação dos mutantes

• Introduzir pequenas alterações semânticas através de pequenas alterações sintáticas que representam defeitos típicos

Operadores dependem da linguagem alvo

• Ex: FORTRAN (22 operadores), C (71 operadores)

read x, y, z m := x if m < y

m := y if m < z

m := z print m

read x, y, z m := x ifm m ≠≠≠≠≠≠≠≠yy

m := y if m < z

m := z print m X = 4

Y = 2 Z = 1

4 2

Aplica

Aplicaç ção de Crit ão de Crité érios rios

Estudos Teóricos e Experimentais avaliam:

• Custo

esforço necessário para que o critério seja utilizado # de casos de teste para satisfazer o critério

• Strength

Dificuldade de satisfação

Dificuldade de satisfazer um critério, tendo satisfeito outro.

• Eficácia

Capacidade que um critério possui de detectar erros

Estratégia Incremental de Teste

• Custo benefício da combinação de critérios

Ambiente de Teste, Depuração e Manutenção de Software

• Facilitam a aplicação de diferentes critérios para o teste

(39)

Exercícios de Fixação

1. Utilização da Técnica de Particionamento por Equivalência

Programa para verificação de tipos de triângulo 2. Utilização da Análise do Valor Limite

Programa para verificação de temperatura e pressão críticas em indústria química

3. Utilização do Grafo de Causa – Efeito

Programa para cálculo de valor de ligação em um programa de uma companhia telefônica

Módulo II – Conclusões

As técnicas de teste atualmente existente são complementares e podem ser utilizadas em conjunto

• Deve ser feita uma análise de custo-benefício na empresa a respeito da aplicação de várias técnicas em conjunto.

Diferente tipos de aplicações (ex: 00, aplicações web, software embarcados) possuem características específicas

• Isso impacta nas atividades desenvolvimento e testes Técnicas diferenciadas para desenvolvimento e testes

Apoio Ferramental é essencial para a aplicação dessas técnicas como meio para reduzir o esforço e custo de sua implantação

(40)

M M ódulos III/IV ó dulos III/IV

Estratégias de Projeto, Execução e Controle dos Testes

M

Mó ó dulos III/IV: Roteiro dulos III/IV: Roteiro

Estratégias de Teste

Explorando Casos de Uso para o Teste Projetando Testes a partir de Caso de Uso Definindo e Configurando um Ambiente de Teste Executando os Testes

Apoiando a Depuração das Falhas Critério de Parada dos Testes Métricas para avaliação dos testes Conclusões

(41)

Estrat

Estraté égias de Teste gias de Teste Baseada na implementação:

• Tenta-se testar cada linha de código

• Muito caro

• Muito difícil quando se tem vários caminhos

Em OO, às vezes não faz sentido!

Baseada na especificação:

• Cobrirá as imposições e restrições feitas pelos desenvolvedores a partir dos requisitos estabelecidos para o sistema

• Pode apoiar o desenvolvimento do software (teste de integração)

Estrat

Estraté égias de Teste gias de Teste

A freqüência com que cada tipo de usuário utiliza o sistema refletirá a importância relativa das características do sistema.

• Esta freqüência de uso pode ser representada por um perfil operacional

Ter um perfil operacional qualificado representa uma estratégia eficiente para descobrir defeitos que os usuários mais encontrariam.

• Este perfil é difícil de se obter antes do lançamento do produto

Extensões ao modelo de casos de uso podem ser

feitas para se considerar este perfil operacional

(42)

Explorando Casos de Uso para Explorando Casos de Uso para

o Teste o Teste

Provêem uma representação para os requisitos funcionais de um sistema.

Identificam todos os atores que

“disparam” as funcionalidades do sistema.

• Ator: representa um usuário do sistema ou um estímulo de um outro sistema.

Extensão ao modelo de Casos de Extensão ao modelo de Casos de

Uso para apoiar teste Uso para apoiar teste

Casos de uso devem considerar freqüência e criticalidade:

• Freqüência:

define quantas vezes um determinado uso do sistema é realizado num período de tempo.

mais difícil de ser obtida, porém possível de ser estimada

• Criticalidade:

define a importância de um uso do sistema em relação ao contexto geral de utilização

facilmente obtida a partir do julgamento de um especialista do domínio.

Combinando-se estes dois critérios pode-se priorizar os casos de uso mais importantes e mais freqüentes.

(43)

Extensão ao modelo de Casos de Extensão ao modelo de Casos de

Uso para apoiar teste Uso para apoiar teste

A freqüência de utilização do sistema deve ser registrada para cada Ator

O perfil pode ser identificado a partir da análise da

responsabilidade do ator (considerações sobre o domínio).

• Esta característica é utilizada para ordenar os atores face a sua freqüência de utilização individual do sistema.

• Pode-se considerar ordenações relativas (primeiro, segundo,...), implícitas (alto, médio, baixo) ou até percentuais.

Esta técnica não altera o processo básico de escolha de tipos de teste e de dados de entrada:

• a modificação ocorre em como sistematicamente distribuir os casos de teste pelos casos de uso com uma prioridade calculada.

Extensão ao modelo de Casos de Extensão ao modelo de Casos de Uso para apoiar testes: Exemplo Uso para apoiar testes: Exemplo

Modelagem de um sistema bancário simples onde os correntistas podem acessar suas contas através de terminais ATM.

Os funcionários acessarão estas contas através do sistema a ser desenvolvido.

Correntistas podem realizar operações de crédito, débito e verificação de saldo.

Os atores deste exemplo são correntista, caixa, gerente e sistema eletrônico de transferência de fundos.

Realiz arA jus tes Trans E letFundos

Correntis ta

Caix a

Realiz arDepós ito

G erente

Reali z arS aque

(44)

Processo Processo

1. Definir o conjunto completo de atores.

2. Definir o conjunto completo de casos de uso incluindo as associações com os atores.

3. Construir o perfil de uso para cada ator.

4. Calcular a freqüência para cada caso de uso a partir dos perfis dos atores.

5. Combinar as avaliações de freqüência e criticalidade num valor que represente a prioridade de teste.

6. Alocar casos de teste com base na prioridade de teste dos casos de uso.

Template

Template - - Caso de Uso Caso de Uso

ID Caso de Uso: RealizarDepósito Nível UC:Sistema

Cenário:

Atores: Transf. Eletrônica de Fundos, Gerente e Correntista Pré-Condições: Conta deve estar aberta e ativa

Descrição:

Trigger: Ator inicia um depósito numa conta.

Sistema solicita a conta destino e o valor do depósito.

Ator informa o número da conta e valor do depósito.

Sistema responde adicionando o valor depositado.

Sistema atualiza contadores de atividade na conta.

Sistema verifica se valor depositado necessita de notificação e caso necessário, gera a notificação.

Requisitos Relevantes: Capacidade de aumentar valor em conta.

Pós-Condições: Saldo da conta foi incrementado pelo valor depositado.

Seqüências Alternativas: Se a conta não estiver ativa, ativá-la primeiro e depois Realizar o depósito.

Regra de Negócio:

(1) o valor do depósito deve ser maior que R$ 10,00

(2)caso o valor do depósito seja maior que R$10000,00, notificar cliente por e-mail (3)ambos os campos são obrigatórios

Exceções: Número de Conta inválida, Conta inativa e Valor Inválido.

Usos concorrentes:RealizarSaque Casos de Uso relacionados:RealizarSaque Freqüência:

Criticalidade:

Risco:

(45)

Perfil dos Atores Perfil dos Atores

Nome: Funcionário Abstrato:S/n

Descrição (Papel): Tem acesso às contas bancárias Nível Conhecimento: Variado

Perfil de Uso:

Caso de Uso Freqüência Relativa

RealizarSaque Alta

RealizarDepósito Média

RealizarAjustes Baixa

Nome: Caixa Abstrato:N/s

Descrição (Papel): Lida diretamente com os correntistas.

Nível Conhecimento: Treinados, mas com níveis de experiência diversos.

Perfil de Uso:

RealizarSaque Média

RealizarDepósito Alta

RealizarAjustes __

Perfil dos Atores Perfil dos Atores

Nome: Gerente Abstrato:N/s

Descrição (Papel): Supervisiona os caixas e gerencia as contas.

Nível Conhecimento: Especialista.

Perfil de Uso:

RealizarSaque Alta

RealizarAjustes Média

Nome: Correntista Abstrato:N/s

Descrição (Papel): Dono de uma conta, pode disparar atividades na mesma.

Nível Conhecimento: Novato.

Perfil de Uso:

RealizarSaque Alta

RealizarAjustes __

(46)

Perfil dos Atores Perfil dos Atores

Nome: Transferência Eletrônica de Fundos Abstrato:N/s

Descrição (Papel): Inicia atividades na conta, com algumas restrições.

Nível Conhecimento: Especialista.

Perfil de Uso:

RealizarSaque Média

RealizarAjustes __

Avalia

Avaliaç ção de Freq ão de Freqü üência e ência e Criticalidade

Criticalidade

Caso de Uso Freqüência Criticalidade Prioridade de Teste

RealizarDepósito Média Alta Alta

RealizarSaque Alta Alta Média

RealizarAjustes Média Baixa Baixa

(47)

Avalia

Avaliaç ção de Freq ão de Freqü üência e ência e Criticalidade

Criticalidade

RealizarAjustes TransEletFundos

Correntista

Caixa

Realizar Depósito de $1000

Realizar Depósito de $10000

Realziar Depósito c om nº de c onta inválido

RealizarDepósit o

Gerente

RealizarSaque

Projeto dos Testes a partir de Projeto dos Testes a partir de

Casos de Uso Casos de Uso

Um caso de uso é formado por:

• Atores: perfis de usuários que executam o caso de uso

• Pré-condições: restrições para a execução de um caso de uso

• Seqüência de Ações (Fluxo principal): passos ordenados para execução de um caso de uso

• Pós-condições: condição final a ser estabelecida ao final da execução do caso de uso

• Seqüências Alternativas: fluxos de ações que ocorrem paralelamente ao fluxo principal, dada uma ação específica

• Regras de negócio: restrições (regras) para execução de um mais passos do fluxo principal ou alternativo

• Exceções: estados inválidos para o sistema

(48)

Projeto dos Testes a partir dos Projeto dos Testes a partir dos

casos de uso casos de uso

A partir desse conjunto de informações, os testes podem ser gerados, iniciando pelos casos de teste Passos a serem seguidos para geração dos testes

(seguiremos o exemplo do caso de uso Realizar Depósito para o Ator CORRENTISTA, sem maiores regras)

:

1. Identifique os elementos presentes no caso de uso (ex.

itens de menu, campos de formulários, botões, ações alternativas, etc.)

• Itens de Menu: Depósito e Saque

• Campo: conta de destino e valor do depósito.

2. Identifique a dependência entre esses elementos (ex. um campo só pode ser preenchido caso uma opção do caso de uso tenha sido previamente escolhida)

• Os campos conta de destino e valor do depósito só aparecem caso o item de menu “Depósito” tenha sido escolhido anteriormente

Projeto dos Testes a partir dos Projeto dos Testes a partir dos

casos de uso casos de uso

Passos a serem seguidos para geração dos testes:

3. Defina os casos de teste individuais para cada elemento do caso de uso usando uma das técnicas de teste apresentadas (ex. particionamento por equivalência, análise do valor limite, etc.)

• Número de Conta (usando particionamento por equivalência):

• T_con={(“12345-6”, inválida), (“”, inválido), (“24567-2”, válido), (“36265-1”,inválido – inativa)}

• Valor do Depósito (usando análise do valor limite):

• T_val= {nulo(em branco), 9.99; 10; 10000; 10000.01}