Upload
vodang
View
227
Download
0
Embed Size (px)
Citation preview
Engenharia de Software
Verificação e Validação
António Rito [email protected]
Verificação e Validação 2
SumárioObjectivosTécnicasCasos NotáveisExemploConclusões
Verificação e Validação 3
ObjectivoVerificaçã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ário
1. 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, Erros e FaltasFalha – um acontecimento que ocorre num determinado momento e que se desvia do comportamento esperado do sistemaErro – o erro é o estado inconsistente do computador que levou à falhaFalta – é a causa que levou ao erro
Verificação e Validação 5
Causas das FalhasAs 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 omissoA especificação contém um requisito que é impossível de implementarO desenho do sistema possui uma falta que impede a implementação de um requisitoO desenho do programa ou a sua implementação podem estar errados
Verificação e Validação 6
Exemplos de Faltastestar a condição erradaomitir uma vírgulanão saber a prioridade dos operadoreserro de truncaturaincoerência entre a documentação e o códigoexceder a dimensão de uma estruturao desempenho é inaceitável no limite de utilização do sistemarace-conditionsfalha do sistema operativoa codificação não segue as normas...
Verificação e Validação 7
Classificação de TestesEstáticos – análise e verificação das representações
Documentos de requisitosDiagramas de desenhoCódigo fonte
Dinâmicos – exercitar a implementação
Especificação executávelCódigo executável
Verificação e Validação 8
Classificação de TestesOs testes estáticos
Inspecções de programasVerificação formal...
apenas suportam a verificação – o programa está de acordo com a especificação de requisitosOs testes dinâmicos suportam a verificação e a validação
Verificação e Validação 9
Organização dos TestesTeste de Unidade – Verifica a funcionalidade dos componentes para os diversos tipos de entradasTeste de Integração – Verifica se os componentes funcionam conjuntamente como especificado no desenho do sistemaTeste da Funcionalidade – Verifica se as funcionalidades descritas na especificação de requisitos são executadas pelo sistema integrado
Verificação e Validação 10
Organização dos TestesTeste da Não-Funcionalidade –Verifica se o sistema integrado satisfaz os requisitos não-funcionaisTeste de Aceitação – Valida os requisitos do utilizador/cliente de acordo com o documento de requisitosTeste de Instalação – Assegura que o sistema funciona no ambiente onde será usado
Verificação e Validação 11
Equipa de TestesA equipa de desenvolvimento faz teste do unidade e de integraçãoA equipa de testes 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
Verificação e Validação 12
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 13
Semear FaltasUm elemento da equipa de testes insere intencionalmente um conjunto de faltas no programaOs restantes elementos da equipa fazem os testesA 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-inseridasContudo as faltas inseridas podem não ser representativas das faltas não-inseridas
Verificação e Validação 14
Teste de UnidadeVerifica a funcionalidade dos componentes para os diversos tipos de entradas
Verificação e Validação 15
Examinar o CódigoRevisão de Código – rever o código e a documentação para identificar erros de interpretação, incoerências e outras faltas
Percorrer o Código (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ódigoInspecção de Código – 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, ...
Verificação e Validação 16
Sucesso das RevisõesA 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ódigoVários estudos mostraram que 60% a 90% das faltas detectadas foram-no durante as inspecções de código
Verificação e Validação 17
Provas de CorrecçãoUm módulo é correcto se implementa as funções e os dados como indicado no desenho e possui uma interface adequada com os restantes módulosExistem várias técnicas
Prova formalExecução simbólicaProva automática de teoremas
Verificação e Validação 18
Vantagens e DesvantagensVantagens
Prova formal de que funcionaEntendimento formal do programa
DesvantagensProvar que o código é correcto é mais demorado do que fazer o códigoAs provas são complexasAs provas podem estar erradasNão pode ser construído um programa que prove a correcção de qualquer programa
Verificação e Validação 19
Testar os ProgramasAs provas dizem como o programa vai funcionar num ambiente hipotético descrito pelo desenho e pelos requisitos enquanto que os testes são uma série de experiências que dizem como é que o programa vai funcionar no seu ambiente de execuçãoUm caso de teste define uns dados de entrada que devem ser usados para testar o programaUm teste é um conjunto finito de casos de teste
Verificação e Validação 20
Estratégias de TesteCaixa Fechada – 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
Caixa Aberta – 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 21
Processo de Testes1. Definir o objectivo dos testes
Todos os comandos executam adequadamenteTodas 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 ccaixa aberta: examinar o código do módulo, valor de b2-4ac
3. Executar os casos de teste4. Comparar os resultados
Verificação e Validação 22
Dados de TesteOs 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 23
Profundidade de TesteTeste de Comando – cada comando do componente é executado pelo menos uma vezTeste de Alternativa – para cada ponto de decisão do código, cada alternativa é executada pelo menos uma vezTeste de Todos os Caminhos – cada caminho distinto através do código é executado pelo menos uma vez
Verificação e Validação 24
RESULT > 0 ?
X > K ?
PRINT RESULT
POINTER = FALSE 1
NO
YES
YES
NO
CALL SUB (X,POINTER, RESULT)
23
4
5
67
POINTER = TRUE
X = X + 1
Número de Casos de Testes
Verificação e Validação 25
Número de Casos de TestesTeste de Comando
1-2-3-4-5-6-7Teste de Alternativa
1-2-3-4-5-6-71-2-4-5-6-1
Teste de Todos os Caminhos1-2-3-4-5-6-71-2-3-4-5-6-11-2-4-5-6-71-2-4-5-6-1
Verificação e Validação 26
Teste de IntegraçãoVerifica se os componentes funcionam conjuntamente como especificado no desenho do sistema
Verificação e Validação 27
Objectivo e EstratégiasO teste de integração combina os componentes, que foram testados individualmente, num sistemaExistem várias estratégias
Integração Big-BangIntegração de Baixo-Para-CimaIntegração de Cima-Para-Baixo
Verificação e Validação 28
Hierarquia de Componentes
A
DCB
FE G
Verificação e Validação 29
Integração de Big-BangTeste
A
TesteA,B,C,D,
E,F,G
TesteB
TesteD
TesteE
TesteC
TesteF
TesteG
Verificação e Validação 30
Integração Big-BangDifí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 31
Integração de Baixo-Para-CimaCada componente dos níveis mais baixos da hierarquia do sistema é testado individualmente primeiroOs 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
Verificação e Validação 32
Integração de Cima-Para-BaixoOs componentes de topo são testados isoladamenteTodos 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 33
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
Verificação e Validação 34
Teste da FuncionalidadeTesta o que o sistema deve fazer de acordo com os requisitos funcionais do sistemaPara facilitar a detecção da causa de um problema deve-se:
Escolher cuidadosamente a ordem pela qual as funcionalidades são testadasComeçar o teste da funcionalidade ainda antes de o sistema estar completamente construído
Verificação e Validação 35
Teste da FuncionalidadeO teste deve:
Ter uma grande probabilidade de detectar uma faltaUtilizar uma equipa de testes independente dos programadoresSaber quais são as acções e as saídas esperadasTestar entradas válidas e inválidasNunca alterar o sistema apenas para tornar os testes mais simplesTer uma critério de paragem
Verificação e Validação 36
Teste da Não-FuncionalidadeTesta os requisitos não funcionais do sistemaSã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 37
Tipos de Teste NFCarga – testa no contexto de um grande número de utilizadoresVolume – testa o tratamento de uma grande quantidade de dadosConfiguração – testa as várias configurações de software e de hardwareCompatibilidade – testa as interfaces entre sistemasOperacional – testa de acordo com os perfis de utilização
Verificação e Validação 38
Tipos de Teste NFSegurança – testa a confidencialidade e integridade de dados e serviçosDesempenho – testa o tempo de respostaQualidade – testa a fiabilidade, disponibilidade e facilidade de manutenção do sistemaRecuperação – testa a resposta à presença de faltas ou perdas de informação
Verificação e Validação 39
Tipos de Teste NFManutenção – testa as ferramentas de diagnóstico e procedimentos de ajuda para localizar a origem dos problemasDocumentação – verifica a coerência e existência de documentosFactores Humanos – investiga os aspectos relacionados com a interface utilizador, facilidade de utilização, ... (usabilidade)
Verificação e Validação 40
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 41
DefiniçõesFiabilidade – é a probabilidade que um sistema funcione sem falhas numas dados condições e por um dado intervalo de tempoDisponibilidade – é a probabilidade de que o sistema esteja em funcionamento de acordo com a especificação num determinado momentoFacilidade de Manutenção – é a probabilidade que uma actividade de manutenção possa ser levada a cabo num determinado intervalo de tempo
Verificação e Validação 42
Dados sobre FalhasFiabilidade, disponibilidade e facilidade de manutenção são medidos tendo como base informação do passadoDados sobre falhas devem ser mantidos para permitir as medidas:
Tempo entre falhasTempo 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 usadoSucesso das últimas correcções
Verificação e Validação 43
TMPF, TMPR, TMEFTempo médio para falhas (TMPF) é a média do tempo para acontecer a próxima falhaTempo médio para reparação (TMPR) é a média dos tempos de reparaçãoTempo médio entre falhas (TMEF)
TMEF = TMPF + TMPR
Fiabilidade = TMEF / (1 + TMEF)Facilidade de Manutenção = 1 / (1 + TMPR)Disponibilidade = TMEF / (TMEF + TMPR)
Verificação e Validação 44
Estabilidade e FiabilidadeComo 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ávelSe o tempo entre falhas aumenta então a fiabilidade está a aumentar
Verificação e Validação 45
Ambiente OperacionalCapturar 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 utilizadasA fiabilidade destes testes será a fiabilidade que os utilizadores irão perceber
Verificação e Validação 46
Testes de AceitaçãoO 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 expectativasOs testes de aceitação permitem que o cliente verifique o que deseja mesmo que não esteja nos requisitos
Verificação e Validação 47
Tipos de Teste AceitaçãoPiloto – instala o sistema numa base experimental e espera que a utilização diária teste todas as funções do sistemaBenchmark – 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
Verificação e Validação 48
Tipos de Teste AceitaçãoOs testes alfa têm lugar no local onde o software foi desenvolvidoOs testes beta são testes piloto no local do clienteTestes paralelos possibilitam que o sistema execute em paralelo com a versão anterior
Verificação e Validação 49
Testes de InstalaçãoTestes finais que envolvem a instalação do sistema no local do cliente e dos utilizadoresApós a instalação testes regressivostêm lugar para assegurar que o sistema funciona no local de operaçãoQuando o cliente está satisfeito com os resultados, os testes estão completos e o sistema é formalmente entregue
Verificação e Validação 50
Ferramentas AutomáticasFerramentas de teste são muitas vezes essenciaisExistem ferramentas para:
Análise de códigoExecução de testesGeração de casos de teste
Verificação e Validação 51
Análise de CódigoAnálise estática – tem lugar quando o programa não está a executarAnálise dinâmica – tem lugar quando o programa está em execução
Verificação e Validação 52
Análise EstáticaAnalisador de Código – verifica a sintaxe fazendo realce no caso de errosAnalisador de Dados – analisa as estruturas de dados, e.g. mostra utilização ilegal dos dadosVerificador de Sequências – 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 53
Análise DinâmicaSão também chamados de monitores ou depuradores porque observam e relatam acerca do comportamento do programaFazem o traço de execução do programaColocam pontos de paragem para parar a execução e permitir analisar os estado do programaExaminam e alteram o conteúdo da memória
Verificação e Validação 54
Execução de Testes Ferramentas de automatizam a planificação dos testes e podem até executar os testesCapturar 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 humanoRe-executam os eventos gravados
Verificação e Validação 55
Ambientes de TesteAs 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 testesEditores de textoFerramentas de análise de código...
Verificação e Validação 56
Geração de Casos de TesteGeradores estruturais baseiam os casos de teste na estrutura do código fonte de forma a se obter a melhor coberturaGeradores baseados na funcionalidade exercitam todos os possíveis casos que afectam a terminação de cada funcionalidadeGeradores baseados nas variáveis exercitam todos os valores de cada variável
Verificação e Validação 57
Casos NotáveisPadrões de Teste de Sistema
Patterns for System Testing. David E. DeLano et al. In Martin97. Capítulo 28http://www.agcs.com/supportv2/techpapers/patterns/papers/systestp.htm
Verificação e Validação 58
Padrões de Teste de SistemaOrganização dos Testes – da relação da equipa de testes com o resto da organizaçãoEficiência dos Testes – identificar em que áreas existe maior probabilidade de haver errosEstratégia de Teste – após se iniciarem os testes ajudar a encontrar problemasResolução dos Problemas – ajudar na comunicação e resolução de problemas
Verificação e Validação 59
Contexto ComumO sistema está em desenvolvimento e novas funcionalidades vão sendo introduzidasAs funcionalidades estão a ser desenvolvidas a pedido dos clientes que as vendem depois aos utilizadores finaisA introdução de novas funcionalidades pode introduzir erros nas funcionalidades antigas
Verificação e Validação 60
Contexto ComumAs funcionalidades são implementadas por uma equipa de programadores que são também responsáveis pelos testes de unidade e de integraçãoO sistema é não determinista pelo que o conjunto de possíveis testes é muito grandeO número de testes regressivos aumenta em cada versão pelo que é demorado refazer todos os testes
Verificação e Validação 61
Contexto ComumExiste uma equipa de testes que os efectua em paralelo com a implementaçãoA equipa de testes faz testes de caixa fechada
Verificação e Validação 62
Forças ComunsO tempo para testes é curtoReduzir o tempo de desenvolvimento pode levantar problemasReduzir a duração de teste pode levar a que não se identifiquem problemas críticosNem todos os problemas podem ser encontradosÉ aceitável uma versão com problemas não críticos
Verificação e Validação 63
Forças ComunsAs especificações são por vezes pouco claras ou ambíguasOs problemas devem ser encontrados o mais cedo possívelReportar problemas pode ser visto como algo negativoA estabilidade do software é críticaOs programadores têm usualmente mais prestígio que a equipa de testes
Verificação e Validação 64
Forças ComunsOs programadores estão mais preocupados com a sua área de trabalhoA equipa de testes deve ter uma visão global do sistemaOs utilizadores finais nem sempre usam as funcionalidades como especificado pelo cliente
Verificação e Validação 65
Organização dos TestesPadrões da relação da equipa de testes com o resto da organização
A equipa de testes é mais importante que os casos de testesOs programadores são nossos amigosEnvolver-se cedoQuando testarDar tempo
Verificação e Validação 66
Equipa Mais Importante do que...Problema – Como atribuir tarefas à equipa de modo a ter a eficiência máxima?Forças – Nem todos os elementos da equipa têm as mesmas capacidadesSolução – Atribuir tarefas de acordo com a experiência e o talentoRacional – O mesmo teste pode não produzir o mesmo resultado quando levado a efeito por diferentes elementos da equipa
Verificação e Validação 67
Programadores São Nossos AmigosProblema – Como é que a equipa de testes pode trabalhar eficientemente com os programadores?Solução – Criar um relacionamento com os programadores de modo a terem um objectivo comumRacional – A personalização dos problemas torna os programadores defensivos
Verificação e Validação 68
Envolver-se CedoProblema – Como é que a equipa de testes pode maximizar o apoio dos programadores?Forças – Durante as fases iniciais do projecto a equipa tem planos de teste para escreverSolução – Criar um bom relacionamento com os programadores participando na aquisição de requisitos conjuntamente com os programadores
Verificação e Validação 69
Quando TestarProblema – Quando testar?Forças
Os programadores não querem que os testes se iniciem até estar tudo perfeitoA equipa quer começar a testar o mais cedo possívelTestar um sistema incompleto pode obrigar a re-testar mais tarde
Solução – começar a testar quando uma área funcional está pronta para testes
Verificação e Validação 70
Dar TempoProblema – Quanto tempo deve ser dados aos programadores para terminarem o trabalho que já está atrasado de acordo com o plano de testes?Solução – dar aos programadores mais tempo dentro de um intervalo aceitávelRacional – Sistemas de maior qualidade levam menos tempo a testar
Verificação e Validação 71
Eficiência dos TestesPadrões para identificar em que áreas existe maior probabilidade de haver erros
Interfaces inalteradasDocumentação ambíguaUtilizar relatórios passados
Verificação e Validação 72
Interfaces InalteradasProblema – Como deve ser testada a funcionalidade de uma interface desenvolvida por uma terceira entidade?Forças
O conhecimento do componente é limitadoO projecto assume que o código vai funcionar uma vez que não foi alterado
Solução – 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
Verificação e Validação 73
Documentação AmbíguaProblema – Como é possível identificar áreas onde existe a maior parte dos problemas?Forças – Algumas áreas têm mais tendência a ter problemas do que outrasSolução – Estudar a documentação procurando áreas ambíguas ou mal definidasRacional – A documentação pode ser interpretada de diferentes formas
Verificação e Validação 74
Utilizar Relatórios PassadosProblema – Como é possível identificar áreas onde existe a maior parte dos problemas?Solução
Examinar os relatórios de problemas identificados em versões anteriores de modo a seleccionar os casos de testeDar atenção aos problemas encontrados após as últimas integrações
Racional – Os relatórios de problemas revelam sintomas que é difícil ligar com os problemas reais
Verificação e Validação 75
Estratégia de TestePadrões para após se iniciarem os testes ajudar a encontrar problemas
Carregar o sistemaNão confiar nas simulaçõesPerspectiva do utilizador finalIntercalação inesperadaEsgravatarTeste mortal
Verificação e Validação 76
Carregar o SistemaProblema – em que condições devem os testes do sistema ser feitos de modo a encontrar a maior parte dos problemas?Solução – 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
Verificação e Validação 77
Não Confiar nas SimulaçõesProblema – Como é que o ambiente de teste deve ser configurado quando se usa simulação?Forças
Alguns testes não são possíveis sem simulaçãoNão é possível ter um ambiente real para todos os testes
Solução – Testar o sistema num ambiente o mais próximo possível do mundo realRacional – 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 FinalProblema – Como testar novas funcionalidades sem repetir testes anteriores?Solução
Ter a perspectiva do utilizadorUtilizar a documentação do clienteTestar as interacções de funcionalidades
RacionalOs utilizadores finais não usam o sistema da forma que eles foram desenhadosO utilizador final vê os serviços que o sistema presta não as funcionalidades desenvolvidas pelos programadores
Verificação e Validação 79
Intercalação InesperadaProblema – Que testes adicionais devem ser feitos e que não são cobertos pelos planos de teste de uma área?Solução
Executar os testes mais rápido ou mais lentamente do que esperadoCancelar os testes a meio da sua execução.
Racional – 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
EsgravatarProblema – Uma vez que se iniciaram os testes qual a melhor estratégia para determinar o que testar a seguir?Solução – Testar áreas onde já se detectaram problemasRacional – Os problemas têm tendência a estar em grupos – 50% dos problemas estão em 15% dos módulos
Verificação e Validação 81
Teste MortalProblema – Como determinar qual é a qualidade do sistema em desenvolvimento?Contexto – O desenvolvimento está a terminar e a gestão quer saber quanto falta para o sistema poder ser entregueSolução – Desenvolver um teste mortal, conjunto de casos de teste, que quase sempre detecta errosRacional – 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 ProblemasPadrões para ajudar na comunicação e resolução de problemas
Documentar o problemaAdoptar um problemaProblema irritante
Verificação e Validação 83
Documentar o ProblemaProblema – Como devem os problemas detectados durante os testes ser comunicados?Solução
Escrever um relatório de erroNão discutir com os programadoresNão aceitar uma promessa de que se vai resolver o problemaO projecto não deve ter uma lista privada de problemasOs 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 ProblemaProblema – Como é que um problema recorrente pode ser resolvido?Forças
Alguns problemas são difíceis de reproduzirProblemas ambíguos resultam em correcções ambíguasOs programadores podem não ser capazes de recordar os problemas que não conseguem resolver
SoluçãoAdoptar o problemaPersistir até o problema ser resolvidoRe-testar periodicamente o problema para obter mais dados sobre ele
Verificação e Validação 85
Problema IrritanteProblema – Um problema tem sido debatido até ao ponto de por em causa o progressoSolução
Quando se adopta um problema deve-se ter o cuidado de evitar que o problema se torne em algo incómodo para os programadoresA equipa de testes deve trazer uma terceira entidade, por exemplo a equipa de requisitos, para resolver o impasse
Verificação e Validação 86
ExemploTestes e o processo unificado....JUNIT...
Verificação e Validação 87
ConclusõesP107 – 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
Verificação e Validação 88
P112 – Falácia da Ausência de ErrosUm sistema sem erros pode não fazer o que é pedido
P113 – Um Teste bem Sucedido Encontra um ErroP114 – 50% dos Erros estão em 15% dos MódulosP115 – Utilizar Testes de Caixa Fechada e de Caixa AbertaP116 – Um Caso de Teste Inclui os Resultados Esperados
Conclusões
Verificação e Validação 89
P117 – Testar Entradas InválidasP118 – Fazer Testes de CargaP121 – Utilizar Métricas de Terminação de Teste
Percentagem de novos erros detectados por semanaPercentagem de erros semeados e encontrados
Conclusões
Verificação e Validação 90
ConclusõesP122 – Conseguir uma Cobertura Eficaz dos Testes
Cobertura de comandos, ...
P125 – Analisar as Causas dos ErrosInformar os restantes elementos da equipa de desenvolvimento
P126 – Não Tomar os Erros Pessoalmente
Verificação e Validação 91
ReferênciasPfleeger98, Capítulo7 e 8 exceptuando 7.5, 8.7 e 8.9. Também não foram cobertas as seguintes partes:
Orthogonal Defect Classification p282Configuration Management p336Cause-andEffect Graph p345Reliability Prediction p356
David95, Alguns Princípios do Capítulo 6.
Verificação e Validação 92
ReferênciasDavid E. DeLano and Linda Rising. Patterns for System Testing. In Martin97. Capítulo 28. http://www.agcs.com/supportv2/techpapers/patterns/papers/systestp.htm