8 - verificação e validação - fenix.tecnico.ulisboa.pt · — falha do sistema operativo — a...
TRANSCRIPT
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
Verificação e Validação 3
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
Verificação e Validação 4
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
Verificação e Validação 5
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
Verificação e Validação 6
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
Verificação e Validação 7
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
Verificação e Validação 8
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
Verificação e Validação 9
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
Verificação e Validação 10
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
Verificação e Validação 11
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
Verificação e Validação 12
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
Verificação e Validação 13
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
Verificação e Validação 14
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
Verificação e Validação 15
Teste de Unidade� Verifica a funcionalidade dos
componentes para os diversos tipos de entradas
Verificação e Validação 16
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
Verificação e Validação 17
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
Verificação e Validação 18
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
Verificação e Validação 19
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
Verificação e Validação 20
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
Verificação e Validação 21
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
Verificação e Validação 22
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
Verificação e Validação 23
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
Verificação e Validação 24
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
Verificação e Validação 25
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
Verificação e Validação 26
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
Verificação e Validação 27
Teste de Integração� Verifica se os componentes
funcionam conjuntamente como especificado no desenho do sistema
Verificação e Validação 28
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
Verificação e Validação 29
Hierarquia de Componentes
A
DCB
FE G
Verificação e Validação 30
Integração de Big-BangTeste
A
TesteA,B,C,D,
E,F,G
TesteB
TesteD
TesteE
TesteC
TesteF
TesteG
16
Verificação e Validação 31
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
Verificação e Validação 32
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
Verificação e Validação 33
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
Verificação e Validação 34
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
Verificação e Validação 35
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
Verificação e Validação 36
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
Verificação e Validação 37
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
Verificação e Validação 38
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
Verificação e Validação 39
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
Verificação e Validação 40
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
Verificação e Validação 41
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
Verificação e Validação 42
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
Verificação e Validação 43
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
Verificação e Validação 44
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
Verificação e Validação 45
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
Verificação e Validação 46
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
Verificação e Validação 47
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
Verificação e Validação 48
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
Verificação e Validação 49
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
Verificação e Validação 50
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
Verificação e Validação 51
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
Verificação e Validação 52
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
Verificação e Validação 53
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
Verificação e Validação 54
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
Verificação e Validação 55
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
Verificação e Validação 56
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
Verificação e Validação 57
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
Verificação e Validação 58
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
Verificação e Validação 59
Padrões de Teste de Sistema
Verificação e Validação 60
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
Verificação e Validação 61
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.
Verificação e Validação 62
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
Verificação e Validação 63
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.
Verificação e Validação 64
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
Verificação e Validação 65
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
Verificação e Validação 66
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
Verificação e Validação 67
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.
Verificação e Validação 68
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
Verificação e Validação 69
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.
Verificação e Validação 70
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
Verificação e Validação 71
Eficiência dos Testesidentificar em que áreas existe maior probabilidade de haver erros
� Interfaces inalteradas� Documentação ambígua� Utilizar relatórios passados
Verificação e Validação 72
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
Verificação e Validação 73
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.
Verificação e Validação 74
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
Verificação e Validação 75
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
Verificação e Validação 76
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
Verificação e Validação 77
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.
Verificação e Validação 78
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
Verificação e Validação 79
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.
Verificação e Validação 80
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
Verificação e Validação 81
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.
Verificação e Validação 82
Resolução dos Problemasajudar na comunicação e resolução de problemas
� Documentar o problema� Adoptar um problema� Problema irritante
42
Verificação e Validação 83
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.
Verificação e Validação 84
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
Verificação e Validação 85
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.
Verificação e Validação 86
Testes com Singleton Padrão de desenho Singleton
public class Deployment {
...
public void deploy(File targetFile) {
Deployer.getInstance().deploy(this, targetFile);
}
...
}
44
Verificação e Validação 87
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?
}
}
...
}
Verificação e Validação 88
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 {
...
public void deploy(File targetFile) {
Deployer.getInstance().deploy(this, targetFile);
}
...
}
45
Verificação e Validação 89
Soluçãopublic class Deployment {
private Deployer deployer;
public Deployment(Deployer aDeployer) {
deployer = aDeployer;
}
public void deploy(File targetFile) {
deployer.deploy(this, targetFile);
}
...
}
Verificação e Validação 90
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
Verificação e Validação 91
Exemplo� Testes e o processo unificado....� JUNIT...
Verificação e Validação 92
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
Verificação e Validação 93
� 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
Verificação e Validação 94
� 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
Verificação e Validação 95
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
Verificação e Validação 96
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