objectivo falhas, erros e faltas - autenticação · verificação e validação 4 falhas, erros e...

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


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


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


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


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...


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


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


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


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


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


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 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


Teste de UnidadeVerifica a funcionalidade dos componentes para os diversos tipos de entradas


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, ...


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


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


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


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


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


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


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


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


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


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


Teste de IntegraçãoVerifica se os componentes funcionam conjuntamente como especificado no desenho do sistema


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


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


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


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


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


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


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


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


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


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


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


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)


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çõ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


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


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)


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


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


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


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


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


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


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


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


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


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


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


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...


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


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


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


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


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


Contexto ComumExiste uma equipa de testes que os efectua em paralelo com a implementaçãoA equipa de testes faz testes de caixa fechada


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


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


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


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


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


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


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


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


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


Eficiência dos TestesPadrões para identificar em que áreas existe maior probabilidade de haver erros

Interfaces inalteradasDocumentação ambíguaUtilizar relatórios passados


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


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


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


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


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


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


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


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


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


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


Resolução dos ProblemasPadrões para ajudar na comunicação e resolução de problemas

Documentar o problemaAdoptar um problemaProblema irritante


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


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


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


ExemploTestes e o processo unificado....JUNIT...


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


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


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


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


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.


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

objectivo falhas, erros e faltas - autenticação · verificação e validação 4 falhas, erros e...

Documents