Introdução à Verificação, Validação e Teste (VV&T)*ines/apeti/Auri_Edmund...Verificação e...

Introdução à Verificação, Introdução à Verificação, Validação e Teste (VV&T)*Validação e Teste (VV&T)*

Auri Marcelo Rizzo Vincenzi (UNIVEM) Edmundo Sérgio Spoto (UNIVEM)

Márcio Eduardo Delamaro (UNIVEM){auri, dino, delamaro}@fundanet.br

Essa apresentação foi adaptada de:

• Barbosa E. F.; Maldonado, J. C.; Vincenzi, A. M. R.; Delamaro, M. E.; Souza, S. R. S.; Jino, M. “Introdução ao Teste de Software”, minicurso apresentado no XIV SBES’00, João Pessoa/PA, out, 2000.

• Delamaro, M. E.; Vilela, P. R. “Curso de Treinamento da Telebrás”, 1996.

Workshop de Engenharia de Software – UNESP – SJRP 2

Organização Organização

Ø IntroduçãoØ Teste de SoftwareØ Terminologia e Conceitos BásicosØ Validação e VerificaçãoØ Teste

Ø Técnicas e Critérios de Teste

Ø Perspectivas


IntroduçãoIntrodução

Ø Engenharia de Software

ØObjetivo PrincipalØ Produzir software de alta qualidade e de baixo

custo

Conjunto de princípios, métodos e técnicasque tratam o software como produto de

engenharia que requer planejamento, projeto, implementação e manutenção.



ØQualidade de SoftwareØ Conformidade com requisitos funcionais e de

desempenho, padrões de desenvolvimento documentados, e características implícitas esperadas de todo software profissionalmente desenvolvidoØCorretitude

ØConfiabilidade

Ø Testabilidade



Ø Garantia de Qualidade de SoftwareØ Conjunto de atividades técnicas aplicadas

durante todo o processo de desenvolvimento

ØObjetivoØGarantir que tanto o processo de desenvolvimento

quanto o produto de software atinjam os níveis de qualidade especificados

Ø VV&T – Verificação, Validação e Teste


TerminologiaTerminologia

Ø Defeito Erro FalhaØ Defeito: deficiência mecânica ou algorítmica

que, se ativada, pode levar a uma falhaØ Erro: item de informação ou estado de

execução inconsistenteØ Falha: evento notável em que o sistema

viola suas especificações


Defeitos no ProcessoDefeitos no Processode Desenvolvimentode Desenvolvimento

Ø A maior parte é de origem humanaØ São gerados na comunicação e na

transformação de informaçõesØ Continuam presentes nos diversos produtos de

software produzidos e liberados (10 defeitos a cada 1000 linhas de código)

Ø A maioria encontra-se em partes do código raramente executadas


Defeitos no ProcessoDefeitos no Processode Desenvolvimentode Desenvolvimento

Ø 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


Verificação e ValidaçãoVerificação e Validação

ØGarantia de Qualidade de SoftwareValidação: Assegurar que o produto final corresponda aos requisitos do software

Verificação: Assegurar consistência, completitude e corretitude do produto em cada fase e entre fases consecutivas do ciclo de vida do software

Estamos construindo o produto certo?

Estamos construindo corretamente o produto?



Ø Revisão TécnicaØ A atividade de revisão começou como uma

ferramenta de controle gerencialØRevisão de progresso

ØO progresso não pode ser avaliado simplesmente contando-se o número de tarefas finalizadas

Ø Era preciso estabelecer um meio de avaliar também a qualidade do trabalho executado



Ø Revisão Técnica (cont.)Ø Surgiram então as revisões que avaliam

aspectos técnicos do produtoØQualquer produto pode ser submetido a

uma revisão técnicaØ A técnica pode ser aplicada desde as

primeiras fases do ciclo de vidaØ Formais ou informais



Ø PlanejamentoØ Cabe ao engenheiro de software planejarØo que deve ser revisadoØquais os resultados esperadosØquem deve fazer a revisão

Ø Determinar “checkpoints” dentro do ciclo de vida onde a revisão deve ser aplicada

Ø Determinar resultados esperados



Ø Custo da Remoção de ErrosØ Atividades de projeto são responsáveis por 50 a

65% dos errosØ Revisão pode revelar até 75% desses errosØ Revelar erros cedo diminui o custo de validação e

correçãoØ Fase de projeto: custo 1Ø Fase anterior ao teste: custo 6.5Ø Fase de teste: custo 15Ø Fase de manutenção: custo 60 a 100



Ø Estudo EmpíricoFase Erros

reve lados Cus to

unitário T o t a l

Com rev i sões

Projeto 2 2 1.5 3 3

Antes do tes te 3 6 6.5 234

Durante tes te 1 5 1 5 315

Após l iberação 3 6 7 201

783

Sem revisões Antes do tes te 2 2 6.5 143

Durante tes te 8 2 1 5 1 2 3 0

Após l iberação 1 2 6 7 804

2 1 7 7


Teste e DepuraçãoTeste e Depuração

Ø Teste

Ø Depuração

Processo de executar um programa como objetivo de revelar a presença de defeitos; ou, falhando nesse objetivo, aumentar a confiança

sobre o programa.

Conseqüência não previsível do teste.Após revelada a presença do defeito, ele

deve ser encontrado e corrigido.


Teste de Software Teste de Software

Ø Fundamental em todos os ramos de engenhariaØ Software: produto da Engenharia de Software

Ø Atividade essencial para ascensão ao nível 3 do Modelo CMM/SEI

Ø Atividade relevante para avaliação da característica funcionalidade(ISO 9126,14598-5)


Teste de SoftwareTeste de Software

Ø Inexistência de erro:Ø Software é de alta qualidade?Ø Conjunto de casos de teste T é de baixa qualidade?

?D P

XT

Objetivo: revelar a presença de erros



Ø Defeitos e erros não reveladosØ Falhas se manifestam durante a utilização

pelos usuáriosØ Erros devem ser corrigidos durante a

manutenção

Ø Alto custo



Ø Falhas gravesØ Qualidade e confiabilidade suspeitasØ Modificação do projetoØ Novos testes

Ø Erros de fácil correçãoØ Funções aparentemente funcionam bemØ Qualidade e confiabilidade aceitáveisØ Testes inadequados para revelar a presença de

erros gravesØ Novos testes



Ø Caso de testeØ Especificação de uma entrada para o programa e

a correspondente saída esperadaØ Entrada: conjunto de dados necessários para uma

execução do programaØ Saída esperada: resultado de uma execução do

programa (um oráculo é esperado)

Ø Um bom caso de teste tem alta probabilidade de revelar um erro ainda não descoberto



Ø LimitaçõesØ Não existe um algoritmo de teste de propósito

geral para provar a corretitude de um programaØ Em geral, é indecidível se dois caminhos de um

mesmo programa ou de diferentes programas computam a mesma função

Ø É indecidível se existe um dado de entrada que leve à execução de um dado caminho de um programa; isto é, é indecidível se um dado caminho é executável ou não



Atividades deTeste

Configuraçãode Software

Configuraçãode Teste

Avaliação

Resultadosde Teste

ResultadosEsperados

Dados da Taxade Erros

Modelo deConfiabilidade

Erros

Depuração

Correções

ConfiabilidadePrevista



Ø Fases de TesteØ Teste de Unidade

Ø Identificar erros de lógica e de implementaçãoem cada módulo do software, separadamente

Ø Teste de IntegraçãoØ Identificar erros associados às interfaces entre os

módulos do software

Ø Teste de SistemaØ Verificar se as funções estão de acordo com a

especificação e se todos os elementos do sistema combinam-se adequadamente



Ø Etapas do TesteØ PlanejamentoØ Projeto de casos de testeØ Execução do programa com os casos

de testeØ Análise de resultados


Projeto de Casos de TesteProjeto de Casos de Teste

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

Ø Poucos programadores/analistas gostam de teste e, menos ainda, do projeto de casos de teste


Projeto de Casos de TesteProjeto de Casos de Teste

Ø O projeto de casos de teste é um dos melhores mecanismos para a 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


Técnicas e Critérios de TesteTécnicas e Critérios de Teste

ØManeira sistemática e planejada para conduzir os testes

Ø Conjunto de Casos de Teste TØ Características desejáveis

i) deve ser finitoii) o custo de aplicação deve ser razoável

PD O



Ø Critério de Teste CØ Objetivo

Ø Obter, de maneira sistemática, um conjunto T decasos de teste que seja efetivo quanto à meta principal de teste – revelar a presença de erros no programa

Ø Propriedadesi) incluir todos os desvios de fluxo de execuçãoii) incluir pelo menos um uso de todo resultado

computacionaliii) T mínimo e finito



Ø 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Ø Predicado para avaliar T no teste de PØ T é C-adequado ⇔ todo elemento

requerido por C é exercitado por pelo menos por um t, t ∈ T



Ø Técnica FuncionalØ Requisitos funcionais do softwareØCritério Particionamento em Classes de Equivalência

Ø Técnica EstruturalØ Estrutura interna do programaØCritérios Baseados em Fluxo de ControleØCritérios Baseados em Fluxo de Dados

Ø Técnica Baseada em ErrosØ Erros mais freqüentes cometidos durante o processo de

desenvolvimento de softwareØCritério Análise de Mutantes


Automatização da Atividade de TesteAutomatização da Atividade de Teste

Ø Ferramentas de Teste

Ø Contribuem para reduzir as falhas produzidas pela intervenção humanaØ Aumento da qualidade e produtividade da atividade de

testeØ Aumento da confiabilidade do software

Ø Facilitam a condução de estudos comparativos entre critérios

Para a aplicação efetiva de um critério de teste faz-se necessário o uso de ferramentas automatizadas que

apóiem a aplicação desse critério.


Automatização da Atividade de TesteAutomatização da Atividade de Teste

Ø Critérios Estruturais: Fluxo de DadosØ Asset, Proteste – programas em PascalØ xSuds (xAtac) – programas em C e C++Ø Poke-Tool – programas em C, Cobol e FortranØ JaBUTi – programas e componentes Java (bytecode)

Ø Critérios Baseados em MutaçãoØ Mothra – programas em FortranØ Proteum – programas em C (unidade)Ø Proteum/IM – programas em C (integração)Ø Proteum/RS – especificações


Técnica Funcional (Caixa Preta)Técnica Funcional (Caixa Preta)

Ø 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)Ø Criar casos de teste capazes de checar se essas

funções estão sendo executadas corretamente


Técnica FuncionalTé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


Técnica FuncionalTécnica Funcional

Ø Ferramentas de Apoio ao Teste FuncionalØ JUnit (http://www.junit.org/)

Ø Documentar e descrever casos de teste funcionais

Ø Execução automática dos casos de testeØMuito utilizado em Processos Ágeis de

desenvolvimento


Técnica Estrutural (Caixa Branca)Técnica Estrutural (Caixa Branca)

Ø Baseada no conhecimento da estrutura interna (implementação) do programa

Ø Teste dos detalhes procedimentaisØ A maioria dos critérios dessa técnica

utilizam uma representação de programa conhecida como grafo de programa ou grafo de fluxo de controle


Técnica EstruturalTé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


/* 01 */ {/* 01 */ char achar;/* 01 */ int length, valid_id;/* 01 */ length = 0;/* 01 */ printf (“Identificador: “);/* 01 */ achar = fgetc (stdin);/* 01 */ valid_id = valid_s(achar);/* 01 */ if (valid_id)/* 02 */ length = 1;/* 03 */ achar = fgetc (stdin);/* 04 */ while (achar != '\n')/* 05 */ {/* 05 */ if (!(valid_f(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 */ }

Identifier.c (função main)


1

3

4

5

7

8

11

2

6

910

uc = {achar}

uc = {length}

up = {valid_id}

up = {achar}

up = {achar}

up = {achar}

up = {achar}

up = {valid_id, length}up = {valid_id, length}

up = {valid_id}d = {length, valid_id, achar}

d = {length}

d = {achar, length}

d = {valid_id}

d = {achar}

d = definiçãoup = uso predicativouc = uso computacional



Ø PokeTool: Interface Gráfica



Ø PokeTool: Criando uma Sessão de Teste



Ø PokeTool: Elementos Requeridos



Ø PokeTool: Relatórios de Teste


Técnica Baseada em ErrosTé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Ø Teste de MutaçãoØAnálise de Mutantes (unidade)ØMutação de Interface (integração)


Ø Hipótese do Programador Competente

Ø Efeito de Acoplamento

Programadores experientes escrevem programascorretos ou muito próximos do correto.

Casos de teste capazes de revelar erros simples sãotão sensíveis que, implicitamente, também são capazes

de revelar erros mais complexos.

Teste de MutaçãoTeste de Mutação


Teste de MutaçãoTeste de Mutação

Ø Passos do Teste de Mutação1- Geração de Mutantes

Para modelar os desvios sintáticos mais comuns,operadores de mutação são aplicados a um programa,

transformando-o em programas similares: mutantes.

Mutantes

P1

Pn

P3P2

...

P4

Operadoresde MutaçãoP

Programaem Teste


Análise de MutantesAnálise de Mutantes

Ø Seleção dos operadores de mutaçãoØ AbrangenteØCapaz de modelar a maior parte dos erros

Ø Pequena cardinalidadeØProblemas de custoØQuanto maior o número de operadores

utilizados, maior o número de mutantes gerados



Ø Exemplo de Mutantes

Mutante Gerado pelo Operador ORRN

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

elseprintf ("Invalido\n");

Mutante Gerado pelo Operador OLAN

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

elseprintf ("Invalido\n");



Ø Passos da Análise de Mutantes2 - Execução do ProgramaØExecução do programa com os casos de teste

3 - Execução dos MutantesØExecução dos mutantes com os casos de testeØMutante mortoØMutante vivo

4 - Análise dos Mutantes VivosØMutante equivalenteØ Inclusão de novos casos de testeØEscore de mutação ms(P,T) =

M(P) - EM(P)

DM(P,T)



Ø Ferramenta ProteumØ Critério Análise de MutantesØ Linguagem CØ Outras Características

Ø Importação de casos de testeØ Inserção e remoção de casos de teste dinamicamenteØ Casos de teste podem ser habilitados ou desabilitadosØ Seleção dos operadores a serem utilizados

Ø 71 operadores: comandos, operadores, variáveis e constantes

Ø Geração de relatórios



Ø Apresenta um conjunto de programas que podem ser invocados de duas maneirasØ Interface gráficaØMais fácilØConstante interação com o testador

Ø ScriptsØPossibilitam a condução de uma sessão de teste de

modo programadoØDomínio dos conceitos de mutação e dos programas

que compõem as ferramentas



Ø Proteum: Interface Gráfica



Ø Proteum: Criando uma Sessão de Teste



Ø Proteum: Gerando Mutantes



Ø Relatórios de Teste

(a) (b)


ConclusõesConclusões

Ø Atividades de VV&T são fundamentais no processo de desenvolvimento de software

Ø Quanto mais tarde um erro for descoberto maior o custo associado à sua correção

Ø Desenvolvimento e aplicação de técnicas e critérios de teste

Ø Desenvolvimento e utilização de ferramentas de teste

Ø Estudos teóricos e empíricos para comparar os diversos critérios


PerspectivasPerspectivas

Ø Estratégias de TesteØ Teste de IntegraçãoØ Teste Orientado a ObjetoØ Teste de EspecificaçãoØ Teste de Sistemas ReativosØ Ambiente Integrado para Teste,

Depuração e Manutenção de Software


PerspectivasPerspectivas

Ø Contribuições do grupo (UNIVEM)Ø Estudos Teóricos

Ø Definição e Análise de Critérios de Fluxo de Controle e de Dados para Programas OO e componentes de software

Ø Definição e Análise de Critério de Teste Baseados em Mutação

Ø Definição e Análise de Critérios de Aplicações de Banco de Dados

Ø Estudos EmpíricosØ Comparação de Critérios de Teste

Ø FerramentasØ Poke-ToolØ Proteum e Proteum/IM (Proteum/IM 2.0)Ø JaBUTi


DúvidasDúvidas??????

Introdução à Verificação, Validação e Teste (VV&T)*ines/apeti/Auri_Edmund...Verificação e...

Documents

Transcript of Introdução à Verificação, Validação e Teste (VV&T)*ines/apeti/Auri_Edmund...Verificação e...