8 - Verificação e Validação - fenix.tecnico.ulisboa.pt · — falha do sistema operativo — a...

1

(QJHQKDULD�GH�6RIWZDUH

Verificação e Validação

Carla [email protected]

Verificação e Validação 2

Sumário� Objectivos� Técnicas� Casos Notáveis� Exemplo� Conclusões

2


Objectivo� Verificação – o programa está de

acordo com a especificação (construímos bem o produto?)

� Validação – o programa está de acordo com as expectativas do cliente (construímos o esperado?)

� É necessário1. Identificar as faltas que estão na origem

das falhas – testar 2. Corrigir e remover as faltas – depurar


Falhas e Faltas� )DOKD – um acontecimento que ocorre

num determinado momento e que se desvia do comportamento esperado do sistema

� (UUR – o erro é o estado inconsistente do computador que levou à falha

� )DOWD – é a causa que levou ao erro

3


Causas das Falhas� As causas são diversas e a sua origem está

muito frequentemente associada a ruído de comunicação entre os intervenientes no processo de desenvolvimento:

� A especificação não está de acordo com aquilo que o cliente deseja ou necessita, devido a um requisito errado ou omisso

� A especificação contém um requisito que é impossível de implementar

� O desenho do sistema possui uma falta que impede a implementação de um requisito

� O desenho do programa ou a sua implementação podem estar errados


Exemplos de Faltas� testar a condição errada� omitir uma vírgula� não saber a prioridade dos operadores� erro de truncatura� incoerência entre a documentação e o

código� exceder a dimensão de uma estrutura� o desempenho é inaceitável no limite

de utilização do sistema

4


Exemplos de Faltas� race-conditions� desempenho não satisfaz os requisitos� o comportamento nas situações de

falha não está de acordo com o especificado

� falha do sistema operativo� a codificação não segue as normas


Classificação de Testes� Estáticos – análise e verificação das

representações� Documentos de requisitos� Diagramas de desenho� Código fonte

� Dinâmicos – exercitar a implementação

� Especificação executável� Código executável

5


Classificação de Testes� Os testes estáticos

� Inspecções de programas� Verificação formal� ...

apenas suportam a verificação – o programa está de acordo com a especificação de requisitos

� Os testes dinâmicos suportam a verificação e a validação


Organização dos Testes� 7HVWH�GH�8QLGDGH – Verifica a

funcionalidade dos componentes para os diversos tipos de entradas

� 7HVWH�GH�,QWHJUDomR – Verifica se os componentes funcionam conjuntamente como especificado no desenho do sistema

� 7HVWH�GD�)XQFLRQDOLGDGH – Verifica se as funcionalidades descritas na especificação de requisitos são executadas pelo sistema integrado

6


Organização dos Testes� 7HVWH�GD�1mR�)XQFLRQDOLGDGH –

Verifica se o sistema integrado satisfaz os requisitos não-funcionais

� 7HVWH�GH�$FHLWDomR – Valida os requisitos do utilizador/cliente de acordo com o documento de requisitos

� 7HVWH�GH�,QVWDODomR – Assegura que o sistema funciona no ambiente onde será usado


Equipa de Testes� $�HTXLSD�GH�GHVHQYROYLPHQWR faz

teste do unidade e de integração� $�HTXLSD�GH�WHVWHV faz o teste da

funcionalidade, não-funcionalidade, ...� Os testes podem por em causa os

programadores pelo que deve ser definido um contexto de teste onde os programadores são vistos como parte de um sistema e não os directos responsáveis pelas faltas

7


Quando Parar de Testar� Pode-se alguma vez ter a certeza de

que não existem mais faltas?

Probabilidadede existiremmais faltas

Número de faltas encontradas


Semear Faltas� Um elemento da equipa de testes insere

intencionalmente um conjunto de faltas no programa

� Os restantes elementos da equipa fazem os testes

� A relação entre o número de faltas inseridas encontradas e o número total de inseridas deve ser semelhante ao número de faltas não-inseridas encontradas e o número total de faltas não-inseridas

� Contudo as faltas inseridas podem não ser representativas das faltas não-inseridas

8


Teste de Unidade� Verifica a funcionalidade dos

componentes para os diversos tipos de entradas


Examinar o Código� 5HYLVmR�GH�&yGLJR – rever o código e a

documentação para identificar erros de interpretação, incoerências e outras faltas

� 3HUFRUUHU�R�&yGLJR (Code Walk-throughs): o código e a respectiva documentação são apresentados pelo programador à equipa de revisão, o programador dirige a discussão e a equipa de revisão comenta sobre a correcção do código

� ,QVSHFomR�GH�&yGLJR – a equipa de revisão verifica o código e documentação seguindo uma lista pré-definida de aspectos, definição e utilização de tipos de dados, correcção dos algoritmos, ...

9


Sucesso das Revisões� A ideia de ter alguém a examinar o

nosso código pode ser desconfortável mas as revisões de código têm-se revelado muito eficazes

� A inspecção de código é mais eficaz que percorrer o código

� Vários estudos mostraram que 60% a 90% das faltas detectadas foram-no durante as inspecções de código


Provas de Correcção� Um módulo é FRUUHFWR se implementa

as funções e os dados como indicado no desenho e possui uma interface adequada com os restantes módulos

� Existem várias técnicas� Prova formal� Execução simbólica� Prova automática de teoremas

10


Vantagens e Desvantagens� Vantagens

� Prova formal de que funciona� Entendimento formal do programa

� Desvantagens� Provar que o código é correcto é mais

demorado do que fazer o código� As provas são complexas� As provas podem estar erradas� Não pode ser construído um programa que

prove a correcção de qualquer programa


Testar os Programas� As provas dizem como o programa vai

funcionar num ambiente hipotético descrito pelo desenho e pelos requisitos enquanto que os WHVWHV são uma série de experiências que dizem como é que o programa vai funcionar no seu ambiente de execução

� Um FDVR�GH�WHVWH define uns dados de entrada que devem ser usados para testar o programa

� Um WHVWH é um conjunto finito de casos de teste

11


Estratégias de Teste� &DL[D�)HFKDGD – os testes são feitos

ignorando a estrutura interna do objecto verificando apenas quais são as saídas produzidas para cada entrada

� Pode não permitir escolher um conjunto significativo de casos de teste

� &DL[D�$EHUWD – os testes têm em consideração a estrutura do objecto a ser testado para o testar de diferentes formas

� Pode ser difícil testar todos os caminhos


Processo de Testes1. Definir o objectivo dos testes

� Todos os comandos executam adequadamente� Todas as funções executam correctamente

2. Escolher a estratégia de teste e identificar os casos de teste

� caixa fechada: identificar todas as possíveis entradas, valores de a, b e c

� caixa aberta: examinar o código do módulo, valor de b2-4ac

3. Executar os casos de teste4. Comparar os resultados

12


Dados de Teste� Os dados de teste devem ser

agrupados em classes com as seguintes propriedades

1. Qualquer possível entrada pertence a uma das classes

2. Nenhuma entrada pertence a mais do que uma das classes

3. Se a execução mostra uma falta para uma entrada então a execução para qualquer outra entrada da classe deve mostrar a mesma falta


Profundidade de Teste� 7HVWH�GH�&RPDQGR – cada comando

do componente é executado pelo menos uma vez

� 7HVWH�GH�$OWHUQDWLYD – para cada ponto de decisão do código, cada alternativa é executada pelo menos uma vez

� 7HVWH�GH�7RGRV�RV�&DPLQKRV – cada caminho distinto através do código é executado pelo menos uma vez

13


5(68/7�!��"

;�!�.�"

35,17�5(68/7

32,17(5� �)$/6( �

12

<(6

<(6

12

&$//�68%��;�32,17(5��5(68/7�

��

�

�

��

32,17(5� �758(

;� �;��

Número de Casos de Testes


Número de Casos de Testes� Teste de Comando

� 1-2-3-4-5-6-7� Teste de Alternativa

� 1-2-3-4-5-6-7� 1-2-4-5-6-1

� Teste de Todos os Caminhos� 1-2-3-4-5-6-7� 1-2-3-4-5-6-1� 1-2-4-5-6-7� 1-2-4-5-6-1

14


Teste de Integração� Verifica se os componentes

funcionam conjuntamente como especificado no desenho do sistema


Objectivo e Estratégias� O teste de integração combina os

componentes, que foram testados individualmente, num sistema

� Existem várias estratégias� Integração Big-Bang� Integração de Baixo-Para-Cima� Integração de Cima-Para-Baixo

15


Hierarquia de Componentes

A

DCB

FE G


Integração de Big-BangTeste

A

TesteA,B,C,D,

E,F,G

TesteB

TesteD

TesteE

TesteC

TesteF

TesteG

16


Integração Big-Bang� Difícil localizar a causa das falhas

pois todos os componentes são integrados de uma vez só

� As faltas de interface entre componentes não podem ser facilmente distinguidas de outros tipos de faltas


Integração de Baixo-Para-Cima� Cada componente dos níveis mais

baixos da hierarquia do sistema é testado individualmente primeiro

� Os componentes a testar a seguir são os que invocam os de baixo

� �� adequada à programação com objectos

� �� os componentes de topo (no paradigma de desenvolvimento funcional) são normalmente os mais importantes a ser testados

17


Integração de Cima-Para-Baixo� Os componentes de topo são testados

isoladamente� Todos os componentes invocados pelos

componentes já testados são integrados e testados conjuntamente

TesteA

TesteA,B,C,D

TesteA,B,C,D,

E,F,G


Integração de Cima-Para-Baixo� �� todos os aspectos e faltas associados

aos aspectos funcionais podem ser detectados logo de inicio

� �� é necessário definir stubs para simular os componentes abaixo

� �� a escrita de stubs pode ser difícil devido ao elevado número de condições a ser testadas

� �� os stubs têm de ser testados para se verificar da sua correcção

� �� um grande número de stubs é requerido

18


Teste da Funcionalidade� Testa o que o sistema deve fazer de

acordo com os requisitos funcionais do sistema

� Para facilitar a detecção da causa de um problema deve-se:

� Escolher cuidadosamente a ordem pela qual as funcionalidades são testadas

� Começar o teste da funcionalidade ainda antes de o sistema estar completamente construído


Teste da Funcionalidade� O teste deve:

� Ter uma grande probabilidade de detectar uma falta

� Utilizar uma equipa de testes independente dos programadores

� Saber quais são as acções e as saídas esperadas

� Testar entradas válidas e inválidas� Nunca alterar o sistema apenas para

tornar os testes mais simples� Ter uma critério de paragem

19


Teste da Não-Funcionalidade� Testa os requisitos não funcionais

do sistema� São difíceis de gerir e requerem

que os requisitos não funcionais tenham sido escritos de modo a serem testáveis


Tipos de Teste NF� &DUJD – testa no contexto de um

grande número de utilizadores� 9ROXPH – testa o tratamento de uma

grande quantidade de dados� &RQILJXUDomR – testa as várias

configurações de software e de hardware

� &RPSDWLELOLGDGH – testa as interfaces entre sistemas

� 2SHUDFLRQDO – testa de acordo com os perfis de utilização

20


Tipos de Teste NF� 6HJXUDQoD – testa a confidencialidade

e integridade de dados e serviços� 6LQFURQL]DomR – testa o tempo de

resposta� 4XDOLGDGH – testa a fiabilidade,

disponibilidade e facilidade de manutenção do sistema

� 5HFXSHUDomR – testa a resposta à presença de faltas ou perdas de informação


Tipos de Teste NF� 0DQXWHQomR – testa as ferramentas

de diagnóstico e procedimentos de ajuda para localizar a origem dos problemas

� 'RFXPHQWDomR – verifica a coerência e existência de documentos

� )DFWRUHV�+XPDQRV – investiga os aspectos relacionados com a interface utilizador, facilidade de utilização, ... (usabilidade)

21


Fiabilidade...� Fiabilidade, Disponibilidade e

Facilidade de Manutenção� Estes testes são bastante difíceis de

levar a cabo pois nem sempre podem ser directamente medidos antes da entrega do produto


Definições� )LDELOLGDGH – é a probabilidade que um

sistema funcione sem falhas numas dados condições e por um dado intervalo de tempo

� 'LVSRQLELOLGDGH – é a probabilidade de que o sistema esteja em funcionamento de acordo com a especificação num determinado momento

� )DFLOLGDGH�GH�0DQXWHQomR – é a probabilidade que uma actividade de manutenção possa ser levada a cabo num determinado intervalo de tempo

22


Dados sobre Falhas� Fiabilidade, disponibilidade e facilidade de

manutenção são medidos tendo como base informação do passado

� Dados sobre falhas devem ser mantidos para permitir as medidas:

� Tempo entre falhas� Tempo de cada manutenção

� Existem sempre dois tipos de incerteza na verificação de quando vai ser a próxima falta:

� Como o sistema vai ser usado� Sucesso das últimas correcções


TMPF, TMPR, TMEF� Tempo médio para falhas (TMPF) é a média

do tempo para acontecer a próxima falha� Tempo médio para reparação (TMPR) é a

média dos tempos de reparação� Tempo médio entre falhas (TMEF)

� TMEF = TMPF + TMPR� Fiabilidade = TMEF / (1 + TMEF)� Facilidade de Manutenção = 1 / (1 + TMPR)� Disponibilidade = TMEF / (TMEF + TMPR)

23


Estabilidade e Fiabilidade� Como se pode verificar se a

qualidade do software está a melhorar� Se o tempo entre falhas permanece o

mesmo então a fiabilidade está estável

� Se o tempo entre falhas aumenta então a fiabilidade está a aumentar


Ambiente Operacional� Capturar os perfis operacionais que

descrevem a utilização típica do sistema, e.g. % de criações, % de modificações, ...

� Casos de teste são definidos de acordo com os perfis de utilização

� O teste concentra-se nas partes do sistema que terão mais tendência a ser utilizadas

� A fiabilidade destes testes será a fiabilidade que os utilizadores irão perceber

24


Testes de Aceitação� O cliente dirige os testes e define

os casos a testar de modo a permitir que os clientes e utilizadores determinem se o sistema realmente satisfaz as suas necessidades e expectativas

� Os testes de aceitação permitem que o cliente verifique o que deseja mesmo que não esteja nos requisitos


Tipos de Teste Aceitação� 3LORWR – instala o sistema numa base

experimental e espera que a utilização diária teste todas as funções do sistema

� %HQFKPDUN – o cliente usa um conjunto de casos de teste que representam as condições típicas de utilização. Pode servir para escolher entre vários sistemas

25


Tipos de Teste Aceitação� Os testes DOID têm lugar no local

onde o software foi desenvolvido� Os testes EHWD são testes piloto no

local do cliente� 7HVWHV�SDUDOHORV possibilitam que

o sistema execute em paralelo com a versão anterior


Testes de Instalação� Testes finais que envolvem a instalação

do sistema no local do cliente e dos utilizadores

� Após a instalação WHVWHV�UHJUHVVLYRVtêm lugar para assegurar que o sistema funciona no local de operação

� Quando o cliente está satisfeito com os resultados, os testes estão completos e o sistema é formalmente entregue

26


Ferramentas Automáticas� Ferramentas de teste são muitas

vezes essenciais� Existem ferramentas para:

� Análise de código� Execução de testes� Geração de casos de teste


Análise de Código� $QiOLVH�HVWiWLFD – tem lugar quando

o programa não está a executar� $QiOLVH�GLQkPLFD – tem lugar quando

o programa está em execução

27


Análise Estática� $QDOLVDGRU�GH�&yGLJR – verifica a

sintaxe fazendo realce no caso de erros� $QDOLVDGRU�GH�'DGRV – analisa as

estruturas de dados, e.g. mostra utilização ilegal dos dados

� 9HULILFDGRU�GH�6HTXrQFLDV – verifica as sequências de eventos, e.g. verifica que todos os ficheiros são abertos antes de serem acedidos


Análise Dinâmica� São também chamados de monitores

ou depuradores porque observam e relatam acerca do comportamento do programa

� Fazem o traço de execução do programa

� Colocam pontos de paragem para parar a execução e permitir analisar os estado do programa

� Examinam e alteram o conteúdo da memória

28


Execução de Testes � Ferramentas de automatizam a

planificação dos testes e podem até executar os testes

� Capturar e Re-executar: Gravam sequências de teclas, movimentos

de rato, clicks de rato e entradas durante a execução de um teste por um humano

Re-executam os eventos gravados


Ambientes de Teste� As ferramentas de execução de testes

podem ser integradas com outras ferramentas de modo a constituir um ambiente de teste:

Partilham uma base de dados de testes Editores de texto Ferramentas de análise de código ...

29


Geração de Casos de Teste� Geradores de casos de teste estruturais

baseiam os casos de teste na estrutura do código fonte de forma a se obter a melhor cobertura

� Geradores baseados na funcionalidade exercitam todos os possíveis casos que afectam a terminação de cada funcionalidade

� Geradores baseados nas variáveis exercitam todos os valores de cada variável


Casos Notáveis Padrões de Teste de Sistema

� Patterns for System Testing. David E. DeLano et al.

� In Martin97. Capítulo 28� http:/ /www.agcs.com/supportv2/ techpapers/patte

rns/papers/systestp.htm Testes com Singleton

� Use Your Singletons Wisely. J.B. Rainsberger� http:/ /www-

106.ibm.com/developerworks/webservices/ library/co-single.html?dwzone= webservices

30


Padrões de Teste de Sistema


Padrões de Teste de Sistema� Organização dos testes – da relação da

equipa de testes com o resto da organização

� Eficiência dos testes – identificar em que áreas existe maior probabilidade de haver erros

� Estratégia de teste – após se iniciarem os testes ajudar a encontrar problemas

� Resolução dos problemas – ajudar na comunicação e resolução de problemas

31


Contexto Comum O sistema está em desenvolvimento e novas

funcionalidades vão sendo introduzidas. As funcionalidades estão a ser desenvolvidas

a pedido dos clientes que as vendem depois aos utilizadores finais.

A introdução de novas funcionalidades pode introduzir erros nas funcionalidades antigas.

As funcionalidades são implementadas por uma equipa de programadores que são também responsáveis pelos testes de unidade e de integração.


Contexto Comum� O sistema é não determinista pelo que

o conjunto de possíveis testes é muito grande.

� O número de testes regressivos aumenta em cada versão pelo que é demorado refazer todos os testes.

� Existe uma equipa de testes que os efectua em paralelo com a implementação.

� A equipa de testes faz testes de caixa fechada.

32


Forças Comuns O tempo para testes é curto. Reduzir o tempo de desenvolvimento pode

levantar problemas. Reduzir a duração de teste pode levar a que

não se identifiquem problemas críticos. Nem todos os problemas podem ser

encontrados. É aceitável uma versão com problemas não

críticos. As especificações são por vezes pouco claras

ou ambíguas. Os problemas devem ser encontrados o mais

cedo possível.


Forças Comuns Reportar problemas pode ser visto como algo

negativo. A estabilidade do software é crítica. Os programadores têm usualmente mais

prestígio que a equipa de testes. Os programadores estão mais preocupados

com a sua área de trabalho. A equipa de testes deve ter uma visão global

do sistema. Os utilizadores finais nem sempre usam as

funcionalidades como especificado pelo cliente.

33


Organização dos Testesda relação da equipa de testes com o resto da organização

� A equipa de testes é mais importante que os casos de testes

� Os programadores são nossos amigos� Envolver-se cedo� Quando testar� Dar tempo


Equipa Mais Importante do que...� 3UREOHPD�– Como atribuir tarefas à

equipa de modo a ter a eficiência máxima?

� )RUoDV – Nem todos os elementos da equipa têm as mesmas capacidades.

� 6ROXomR – Atribuir tarefas de acordo com a experiência e o talento.

� 5DFLRQDO – O mesmo teste pode não produzir o mesmo resultado quando levado a efeito por diferentes elementos da equipa.

34


Programadores São Nossos Amigos� 3UREOHPD – Como é que a equipa de

testes pode trabalhar eficientemente com os programadores?

� 6ROXomR – Criar um relacionamento com os programadores de modo a terem um objectivo comum.

� 5DFLRQDO – A personalização dos problemas torna os programadores defensivos.


Envolver-se Cedo� 3UREOHPD – Como é que a equipa de

testes pode maximizar o apoio dos programadores?

� )RUoDV – Durante as fases iniciais do projecto a equipa tem planos de teste para escrever.

� 6ROXomR – Criar um bom relacionamento com os programadores participando na aquisição de requisitos conjuntamente com os programadores.

35


Quando Testar� 3UREOHPD – Quando testar?� )RUoDV –

Os programadores não querem que os testes se iniciem até estar tudo perfeito.

� A equipa quer começar a testar o mais cedo possível.

� Testar um sistema incompleto pode obrigar a re-testar mais tarde.

� 6ROXomR – começar a testar quando uma área funcional está pronta para testes.


Dar Tempo� 3UREOHPD – Quanto tempo deve ser

dados aos programadores para terminarem o trabalho que já está atrasado de acordo com o plano de testes.

� 6ROXomR – dar aos programadores mais tempo dentro de um intervalo aceitável.

� 5DFLRQDO – Sistemas de maior qualidade levam menos tempo a testar.

36


Eficiência dos Testesidentificar em que áreas existe maior probabilidade de haver erros

� Interfaces inalteradas� Documentação ambígua� Utilizar relatórios passados


Interfaces Inalteradas 3UREOHPD – Como deve ser testada a

funcionalidade de uma interface desenvolvida por uma terceira entidade?

)RUoDV –� O conhecimento do componente é limitado.� O projecto assume que o código vai funcionar

uma vez que não foi alterado. 6ROXomR – Uma vez que ninguém está

atribuído a desenvolver esta funcionalidade a equipa de testes deve ser pró-activa no teste da interface enquanto os programadores desenvolvem novas funcionalidades.

37


Documentação Ambígua� 3UREOHPD – Como é possível

identificar áreas onde existe a maior parte dos problemas?

� )RUoDV – Algumas áreas têm mais tendência a ter problemas do que outras.

� 6ROXomR – Estudar a documentação procurando áreas ambíguas ou mal definidas.

� 5DFLRQDO – A documentação pode ser interpretada de diferentes formas.


Utilizar Relatórios Passados 3UREOHPD – Como é possível identificar

áreas onde existe a maior parte dos problemas?

6ROXomR – Examinar os relatórios de problemas identificados em versões anteriores de modo a seleccionar os casos de teste. Dar atenção aos problemas encontrados após as últimas integrações.

5DFLRQDO – Os relatórios de problemas revelam sintomas que é difícil ligar com os problemas reais.

38


Estratégia de Testeapós se iniciarem os testes ajudar a encontrar problemas

� Carregar o sistema� Não confiar nas simulações� Perspectiva do utilizador final� Intercalação inesperada� Esgravatar� Teste mortal


Carregar o Sistema� 3UREOHPD – em que condições devem

os testes do sistema ser feitos de modo a encontrar a maior parte dos problemas?

� 6ROXomR – Testar num ambiente que simule um sistema carregado. O nível de actividade não necessita atingir a carga máxima mas deve ter um grau de utilização elevado.

39


Não Confiar nas Simulações 3UREOHPD – Como é que o ambiente de

teste deve ser configurado quando se usa simulação?

)RUoDV –� Alguns testes não são possíveis sem simulação.� Não é possível ter um ambiente real para todos

os testes. 6ROXomR – Testar o sistema num ambiente o

mais próximo possível do mundo real. 5DFLRQDO – Um simulador pode correr com

sucesso um caso teste centenas de vezes, mas esse caso de teste pode falhar quando executado por um humano.


Perspectiva do Utilizador Final 3UREOHPD – Como testar novas

funcionalidades sem repetir testes anteriores?

6ROXomR – Testar fora do contexto das funcionalidades. Ter a perspectiva do utilizador. Utilizar a documentação do cliente. Testar as interacções de funcionalidades.

5DFLRQDO – Os utilizadores finais não usam o sistema da forma que eles foram desenhados. O utilizador final vê os serviços que o sistema presta não as funcionalidades desenvolvidas pelos programadores.

40


Intercalação Inesperada� 3UREOHPD – Que testes adicionais

devem ser feitos e que não são cobertos pelos planos de teste de uma área?

� 6ROXomR – Executar os testes mais rápido ou mais lentamente do que esperado. Cancelar os testes a meio da sua execução.

� 5DFLRQDO – Os casos de teste que são difíceis de executar são aqueles que provavelmente devem ser executados.


Esgravatar� 3UREOHPD – Uma vez que se iniciaram

os testes qual a melhor estratégia para determinar o que testar a seguir?

� 6ROXomR – Testar áreas onde já se detectaram problemas.

� 5DFLRQDO – Os problemas têm tendência a estar em grupos – 50% dos problemas estão em 15% dos módulos.

41


Teste Mortal 3UREOHPD – Como determinar qual é a

qualidade do sistema em desenvolvimento? &RQWH[WR – O desenvolvimento está a

terminar e a gestão quer saber quanto falta para o sistema poder ser entregue.

6ROXomR – Desenvolver um teste mortal, conjunto de casos de teste, que quase sempre detecta erros.

5DFLRQDO – Um teste que normalmente encontra erros e pode ser executado num curto intervalo de tempo dá uma boa medida de como o sistema está a estabilizar.


Resolução dos Problemasajudar na comunicação e resolução de problemas

� Documentar o problema� Adoptar um problema� Problema irritante

42


Documentar o Problema 3UREOHPD – Como devem os problemas

detectados durante os testes ser comunicados?

6ROXomR – Escrever um relatório de erro. Não discutir com os programadores. Não aceitar uma promessa de que se vai resolver o problema. O projecto não deve ter uma lista privada de problemas. Os programadores não devem ser penalizados quando são documentados problemas de que eles podem estar na origem.


Adoptar um Problema 3UREOHPD – Como é que um problema

recorrente pode ser resolvido? )RUoDV –

� Alguns problemas são difíceis de reproduzir.� Problemas ambíguos resultam em correcções

ambíguas.� Os programadores podem não ser capazes de

recordar os problemas que não conseguem resolver.

6ROXomR – Adoptar o problema. Persistir até o problema ser resolvido. Re-testar periodicamente o problema para obter mais dados sobre ele.

43


Problema Irritante� 3UREOHPD – Um problema tem sido

debatido até ao ponto de por em causa o progresso.

� 6ROXomR – Quando se adopta um problema deve-se ter o cuidado de evitar que o problema se torne em algo incómodo para os programadores. A equipa de testes deve trazer uma terceira entidade, por exemplo a equipa de requisitos, para resolver o impasse.


Testes com Singleton Padrão de desenho Singleton

public class Deployment {

...

public void deploy(File targetFile) {

Deployer.getInstance().deploy(this, targetFile);

}

...

}

44


Objectos Simulados� Os testes de unidade são mais eficazes

quando:� a ligação entre as classes é pequena� é simples usar objectos simulados

public class MyTestCase extends TestCase {

...

public void testBThrowsException() {

MockB b = new MockB();

b.throwExceptionFromMethodC(NoSuchElementException.class);

A a = new A(b); // Pass in the mock version

try {

a.doSomethingThatCallsMethodC();

}

catch (NoSuchElementException success) {

// Check exception parameters?

}

}

...

}


Singletons� Os Singletons aumentam a ligação

entre as classes� os clientes não podem colaborar com

subclasses do servidor� restringem o polimorfismo

public class Deployment {

...


Deployer.getInstance().deploy(this, targetFile);

}

...

}

45


Soluçãopublic class Deployment {

private Deployer deployer;

public Deployment(Deployer aDeployer) {

deployer = aDeployer;

}


deployer.deploy(this, targetFile);

}

...

}


Caso de Testepublic class DeploymentTestCase extends TestCase {

...

public void testTargetFileDoesNotExist() {

MockDeployer deployer = new MockDeployer();

deployer.doNotFindAnyFiles();

try {

Deployment deployment =

new Deployment(deployer);

deployment.deploy(new File("validLocation"));

}

catch (FileNotFoundException success) {

}

}

...

}

46


Exemplo� Testes e o processo unificado....� JUNIT...


Conclusões� P107 – Seguir os Testes até aos

Requisitos� Que requisitos são verificados por cada

teste?� P108 – Planear os Testes Desde Muito

Cedo� Desenvolver os componentes na ordem

mais adequada para os testes� P111 – Os Testes Expõem a Existência

de Faltas� Os testes aumentam a confiança mas não

demonstram que o programa está correcto

47


� P112 – Falácia da Ausência de Erros� Um sistema sem erros pode não fazer o

que é pedido� P113 – Um Teste bem Sucedido

Encontra um Erro� P114 – 50% dos Erros estão em 15%

dos Módulos� P115 – Utilizar Testes de Caixa Fechada

e de Caixa Aberta� P116 – Um Caso de Teste Inclui os

Resultados Esperados

Conclusões


� P117 – Testar Entradas Inválidas� P118 – Fazer Testes de Carga� P121 – Utilizar Métricas de Terminação

de Teste� Percentagem de novos erros detectados

por semana� Percentagem de erros semeados e

encontrados

Conclusões

48


Conclusões� P122 – Conseguir uma Cobertura Eficaz

dos Testes� Cobertura de comandos, ...

� P125 – Analisar as Causas dos Erros� Informar os restantes elementos da

equipa de desenvolvimento

� P126 – Não Tomar os Erros Pessoalmente


Referências� Pfleeger98, Capítulo7 e 8 exceptuando 7.5, 8.7 e 8.9. Também

não foram cobertas as seguintes partes:� Orthogonal Defect Classification p282� Configuration Management p336� Cause-andEffect Graph p345� Reliability Prediction p356

� David95, Alguns Princípios do Capítulo 6.� David E. DeLano and Linda Rising. Patterns for System Testing.

In Martin97. Capítulo 28. http:/ /www.agcs.com/supportv2/ techpapers/patterns/papers/systestp.htm

� J.B. Rainsberger. Use your singletons wisely http:/ /www-106.ibm.com/developerworks/webservices/ library/co-single.html?dwzone= webservices

8 - Verificação e Validação - fenix.tecnico.ulisboa.pt · — falha do sistema operativo — a...

Documents

Transcript of 8 - Verificação e Validação - fenix.tecnico.ulisboa.pt · — falha do sistema operativo — a...