11 - testes de software

Prévia do material em texto

<p>TESTES DE</p><p>SOFTWARE</p><p>Laerte Xavier*</p><p>* Adaptado do material da Prof.a Maria Augusta</p><p>Vieira Nelson e Prof.a Eveline Alonso Veloso</p><p>PUC Minas Engenharia de Software</p><p>Fundamentos de Engenharia de Software</p><p>O que é o Processo de Teste?</p><p>□ É mais um processo;</p><p>! dentro do processo de desenvolvimento de</p><p>software.</p><p>□ Está relacionado a atividades de verificação</p><p>e validação.</p><p>Processo de desenvolvimento</p><p>de softwareProcesso de análise</p><p>de requisitos</p><p>Processo de</p><p>especificação</p><p>do produto Processo de</p><p>desenho Processo de teste</p><p>Verificação Validação</p><p>Fundamentos de Engenharia de Software</p><p>Verificação</p><p>□ “Estamos construindo o produto</p><p>corretamente?”</p><p>□ Processo de avaliar um produto para</p><p>determinar;</p><p>! se os resultados de um passo do processo de</p><p>desenvolvimento de software;</p><p>! satisfazem as condições impostas no início do</p><p>passo.</p><p>□ Conjunto de atividades que verificam se o</p><p>software implementa corretamente uma</p><p>função específica.</p><p>Fundamentos de Engenharia de Software</p><p>Validação</p><p>□ “Estamos construindo o produto certo?”</p><p>□ Processo de avaliar um produto para</p><p>determinar;</p><p>! se ele satisfaz os requisitos especificados.</p><p>□ Conjunto de atividades que validam que o</p><p>software faz aquilo que o usuário</p><p>necessita que ele faça.</p><p>Fundamentos de Engenharia de Software</p><p>Objetivos da Verificação e Validação</p><p>□Descobrir defeitos no sistema.</p><p>□Aferir se o sistema é ou não</p><p>utilizável;</p><p>!em uma situação operacional.</p><p>Fundamentos de Engenharia de Software</p><p>Objetivos da Verificação e Validação</p><p>□ Estabelecer a confiança de que o software</p><p>está apto para seu propósito.</p><p>□ Isso não significa que ele está totalmente</p><p>livre de defeitos;</p><p>! significa que o sistema é bom o suficiente para</p><p>seu uso pretendido.</p><p>□ O tipo de uso determinará o grau de</p><p>confiança necessário.</p><p>Fundamentos de Engenharia de Software</p><p>O Processo de Verificação e Validação</p><p>□ É um processo que ocorre por todo o</p><p>ciclo de vida de desenvolvimento do</p><p>software;</p><p>!verificação e validação devem ser</p><p>aplicadas a cada estágio do processo de</p><p>desenvolvimento de software.</p><p>Fundamentos de Engenharia de Software</p><p>O que é um Teste de Software?</p><p>□ “Testar é o processo de executar um programa;</p><p>! com o intuito específico de encontrar erros;</p><p>■ antes de sua entrega ao cliente ou usuário final.”</p><p>Glenford J. Myers (1979)</p><p>□ “Testar é uma atividade criativa;</p><p>! de geração de ideias;</p><p>! muito mais que uma atividade de implementação.</p><p>! Testar é uma busca heurística;</p><p>■ em um espaço aberto e multidimensional.”</p><p>Cem Kaner (2001)</p><p>Fundamentos de Engenharia de Software</p><p>O que é um Teste de Software?</p><p>□ Atividade na qual um produto é executado</p><p>sob condições especificadas;</p><p>! os resultados são observados e registrados;</p><p>■ e algum aspecto desse produto é avaliado.</p><p>□ Processo usado para revelar defeitos em um</p><p>software;</p><p>! e para estabelecer que o software tem um certo</p><p>grau de qualidade com relação a alguns atributos</p><p>específicos.</p><p>□ É a única técnica de validação de requisitos</p><p>não-funcionais.</p><p>Fundamentos de Engenharia de Software</p><p>O que é um Teste de Software?</p><p>□ Teste é um elemento de garantia da qualidade do</p><p>software.</p><p>□ Pode revelar a presença de erros;</p><p>! mas nunca sua ausência.</p><p>□ Em um primeiro momento, testar é uma atividade</p><p>destrutiva;</p><p>! mas tem o mesmo objetivo do desenvolvimento de software.</p><p>□ Um teste bem-sucedido é aquele que revela um erro</p><p>ainda não descoberto.</p><p>□ A atividade de testes nunca está satisfeita com a</p><p>resposta correta.</p><p>Fundamentos de Engenharia de Software</p><p>O que é um Teste de Software?</p><p>□ Testar não é somente verificar e validar o</p><p>software;</p><p>! essa é apenas metade da atividade.</p><p>□ A outra metade é verificar se ele não faz o que</p><p>não deveria fazer.</p><p>□ Um software deve funcionar não somente quando</p><p>as coisas vão bem;</p><p>! ele deve funcionar quando as coisas vão mal</p><p>também.</p><p>□ Deve-se testar a capacidade do software de</p><p>manipular eventos inesperados;</p><p>! isso demonstra a qualidade do software.</p><p>Fundamentos de Engenharia de Software</p><p>O que é uma Inspeção?</p><p>□ Revisão formal.</p><p>□ Intenção é unicamente a detecção de</p><p>defeitos;</p><p>! não sua correção.</p><p>□ Defeitos podem ser:</p><p>! erros de lógica;</p><p>! anomalias no código;</p><p>■ por exemplo, uma variável não inicializada.</p><p>! não-conformidade com padrões.</p><p>Fundamentos de Engenharia de Software</p><p>Inspeções e Testes</p><p>□ Inspeções e testes são técnicas de verificação</p><p>e validação complementares;</p><p>! ambas devem ser usadas durante o processo de</p><p>verificação e validação.</p><p>□ Inspeções podem verificar a conformidade</p><p>com a especificação;</p><p>! mas não a conformidade com os verdadeiros</p><p>requisitos do cliente.</p><p>□ Inspeções não são capazes de verificar</p><p>características não funcionais como</p><p>desempenho, usabilidade, etc.</p><p>Fundamentos de Engenharia de Software</p><p>O que os Testes de Software Podem</p><p>Mostrar?</p><p>erros</p><p>conformidade ou não com os</p><p>requisitos</p><p>desempenho</p><p>indicação da</p><p>qualidade do</p><p>software</p><p>Fundamentos de Engenharia de Software</p><p>Verificação Estática e Dinâmica</p><p>□ Inspeções de software:</p><p>! verificação estática;</p><p>! lidam com a análise formal da representação estática</p><p>do sistema;</p><p>■ para descobrir defeitos;</p><p>! podem ser suplementadas por ferramentas de análise</p><p>de código.</p><p>□ Testes de software:</p><p>! verificação dinâmica;</p><p>! lidam com o uso e observação do comportamento do</p><p>sistema;</p><p>! o sistema é executado com dados de teste;</p><p>■ e seu comportamento operacional é observado.</p><p>Fundamentos de Engenharia de Software</p><p>Verificação Estática e Dinâmica</p><p>Verificação</p><p>dinâmica</p><p>Especificação</p><p>de requisitos</p><p>Projeto da</p><p>arquitetura</p><p>Projeto</p><p>detalhado</p><p>Código</p><p>Protótipo</p><p>Verificação</p><p>estática</p><p>Fundamentos de Engenharia de Software</p><p>Algumas Definições</p><p>□ Erro:</p><p>! um engano ou mal entendido cometido pelo</p><p>engenheiro de software.</p><p>□ Um defeito é introduzido em um software como</p><p>resultado de um erro.</p><p>! É uma anomalia no software;</p><p>■ que pode levá-lo a comportar-se incorretamente e não de</p><p>acordo com sua especificação.</p><p>□ Falha:</p><p>! inabilidade de um software de funcionar de</p><p>acordo com o esperado.</p><p>! A falha é o sintoma ou a manifestação do erro.</p><p>Fundamentos de Engenharia de Software</p><p>Algumas Definições</p><p>□Caso de teste:</p><p>!Um item de teste que contém:</p><p>■ um conjunto de entradas de teste;</p><p>■ o procedimento de teste a ser executado;</p><p>■ as saídas esperadas.</p><p>Fundamentos de Engenharia de Software</p><p>Classificando os Testes de Software</p><p>Conforme a Visibilidade</p><p>□Testes caixa branca</p><p>□Testes caixa preta</p><p>Fundamentos de Engenharia de Software</p><p>Testes Caixa Branca</p><p>□ Desenvolvidos considerando-se a estrutura</p><p>interna do código;</p><p>! de maneira a exercitá-lo suficientemente.</p><p>Fundamentos de Engenharia de Software</p><p>Testes Caixa Branca</p><p>□ Utilizam a estrutura de controle do</p><p>projeto procedimental para construir os</p><p>casos de teste.</p><p>□ Testador tem que possuir conhecimento da</p><p>estrutura interna do software a ser testado.</p><p>□ Útil para testar componentes pequenos.</p><p>□ Nível de detalhes é grande.</p><p>Fundamentos de Engenharia de Software</p><p>Testes Caixa Branca</p><p>□ Têm como objetivo:</p><p>! garantir que todos os caminhos independentes</p><p>dentro de um módulo;</p><p>■ sejam executados pelo menos uma vez;</p><p>! executar todas as decisões lógicas;</p><p>■ tanto a parte verdadeira quanto a falsa;</p><p>! executar todas as estruturas de repetição;</p><p>■ nos seus limites definidos ou operacionais;</p><p>! garantir a validade das estruturas de dados</p><p>internas.</p><p>Slide elaborado pelo Prof. Humberto Torres da PUC Minas</p><p>Fundamentos de Engenharia de Software</p><p>Testes Caixa Preta</p><p>□ Desenvolvidos considerando-se somente:</p><p>! as entradas aceitas pelo componente;</p><p>! e as saídas esperadas.</p><p>□ Não verificam como ocorre o</p><p>processamento interno;</p><p>! apenas validam os resultados</p><p>produzidos.</p><p>entradas</p><p>requisitos</p><p>eventos</p><p>saídas</p><p>Fundamentos de Engenharia de Software</p><p>Testes Caixa Preta</p><p>□ A partir de um conjunto de condições de entrada</p><p>definidas;</p><p>! verificam por completo todos os requisitos</p><p>funcionais de um software.</p><p>□ Baseados na descrição</p><p>do comportamento do</p><p>software.</p><p>! Software a ser testado é visto como uma “caixa-</p><p>preta”;</p><p>■ não se sabe como funciona sua estrutura interna;</p><p>■ conhece-se apenas o que ele faz.</p><p>! A “caixa preta” pode variar de uma simples função,</p><p>objeto ou módulo, até um sistema completo.</p><p>Fundamentos de Engenharia de Software</p><p>Testes Caixa Preta</p><p>□ Não substituem os testes “caixa-branca”.</p><p>□ Têm como objetivo:</p><p>! identificar a ausência de funções ou funções</p><p>incorretas;</p><p>! identificar erros de interface;</p><p>! identificar erros de comportamento ou de</p><p>desempenho;</p><p>! identificar erros de inicialização e finalização de</p><p>procedimentos;</p><p>! determinar se os requisitos foram total ou</p><p>parcialmente satisfeitos pelo produto.</p><p>Slide elaborado pelo Prof. Humberto Torres da PUC Minas</p><p>Fundamentos de Engenharia de Software</p><p>Quem Testa o Software?</p><p>Desenvolvedor Testador</p><p>Entende muito bem do</p><p>sistema, mas irá testá-lo</p><p>gentilmente, pois está</p><p>preocupado com a data</p><p>da entrega.</p><p>Terá de aprender</p><p>sobre o sistema, mas</p><p>vai fazer de tudo para</p><p>fazê-lo falhar.</p><p>Fundamentos de Engenharia de Software</p><p>Quem Testa o Software?</p><p>□ O próprio desenvolvedor.</p><p>□ Cada programador deve ser responsável por testar;</p><p>! seus componentes em um ambiente isolado.</p><p>□ Testar nosso código;</p><p>! aumenta nossa confiança em nosso próprio trabalho.</p><p>□ Erros encontrados antes de iniciarem-se os testes</p><p>formais do sistema;</p><p>! podem ser consertados a um custo muito mais baixo.</p><p>□ O grupo de testes não consegue desempenhar seu</p><p>papel;</p><p>! se houver erros básicos em componentes.</p><p>□ Testar um sistema;</p><p>! não é suficiente para descobrir erros em seus componentes.</p><p>Fundamentos de Engenharia de Software</p><p>Quem Testa o Software?</p><p>□ Testar é um estado de espírito:</p><p>! “Se o nosso objetivo é mostrar a ausência de</p><p>erros;</p><p>■ nós vamos encontrar poucos deles.</p><p>! Se o nosso objetivo é mostrar a presença de</p><p>erros;</p><p>■ nós vamos descobrir um grande número deles.”</p><p>Glenford J. Myers (1979)</p><p>Fundamentos de Engenharia de Software</p><p>Quem Testa o Software?</p><p>□ Testadores.</p><p>□ Não é interessante que os desenvolvedores</p><p>sejam os únicos responsáveis pelos testes</p><p>de seus códigos;</p><p>! eles têm um envolvimento “afetivo” com o</p><p>código;</p><p>■ um fenômeno psicológico conhecido como dissonância</p><p>cognitiva nos faz aversos a encontrarmos defeitos em</p><p>nossos próprios códigos.</p><p>! testadores, por outro lado, não!</p><p>Fundamentos de Engenharia de Software</p><p>Encontrando Erros</p><p>□ Erros podem ser encontrados de várias formas.</p><p>! Da melhor para a pior:</p><p>1. pelo próprio desenvolvedor;</p><p>■ quando ele está avaliando e estudando o problema</p><p>pela primeira vez;</p><p>2. pelo próprio desenvolvedor;</p><p>■ quando ele está tentando fazer com que o código</p><p>funcione;</p><p>3. por outro desenvolvedor ou testador do grupo;</p><p>4. por esforços de inspeções de código;</p><p>5. como parte de um esforço de testes do produto;</p><p>6. pelo usuário final.</p><p>Fundamentos de Engenharia de Software</p><p>Teste Exaustivo</p><p>□ Geralmente impossível;</p><p>! mesmo para produtos relativamente simples.</p><p>□ A realização de testes, quase sempre, é</p><p>limitada;</p><p>! por restrições de cronograma e orçamento.</p><p>20 vezes</p><p>Quantos caminhos</p><p>possíveis existem?</p><p>Fundamentos de Engenharia de Software</p><p>Primeiro, as Más Notícias…</p><p>□ O processo de testes é:</p><p>! ineficiente;</p><p>■ custo alto por defeito encontrado e corrigido.</p><p>! limitado;</p><p>■ jamais garante que um programa está</p><p>correto.</p><p>! necessário;</p><p>■ não há técnica que reduza defeitos a ponto de</p><p>eliminar a necessidade de se testar.</p><p>Fundamentos de Engenharia de Software</p><p>Por quê o Processo de Testes é</p><p>Limitado?</p><p>□ O software executou código;</p><p>! que não foi testado.</p><p>□ A ordem de execução do código;</p><p>! é diferente da que foi testada.</p><p>□ Os valores reais;</p><p>! estão fora das faixas testadas.</p><p>□ O ambiente de operação;</p><p>! é diferente do testado.</p><p>Fundamentos de Engenharia de Software</p><p>Depois, as Boas Notícias</p><p>□ 40% a 50% do tempo de desenvolvimento de</p><p>software, em média;</p><p>! é gasto em retrabalho evitável.</p><p>□ Testar o código o mais cedo possível;</p><p>! estabiliza-o;</p><p>! tende a diminuir, em muito, o retrabalho.</p><p>□ O tempo gasto com testes, em geral;</p><p>! é bem menor que o gasto com retrabalho.</p><p>□ Testar faz você ter mais tempo;</p><p>! não menos.</p><p>□ Entre 40% e 50% dos sistemas de software em</p><p>operação;</p><p>! contêm defeitos não triviais.</p><p>Fundamentos de Engenharia de Software</p><p>Criando Casos de Teste</p><p>□ É importante planejar e desenhar testes;</p><p>! que consigam o melhor proveito possível dos</p><p>recursos alocados para eles;</p><p>■ antes de executá-los.</p><p>□ Focaliza-se o desenho de testes que tenham</p><p>alta probabilidade de descobrir falhas;</p><p>! com o mínimo esforço.</p><p>Fundamentos de Engenharia de Software</p><p>Criando Casos de Teste</p><p>□ Testadores precisam encontrar um número finito de</p><p>casos de teste;</p><p>! selecionados de um domínio frequentemente muito</p><p>grande.</p><p>□ Objetivo é:</p><p>! maximizar a cobertura:</p><p>■ os testes devem explorar o maior número possível de</p><p>possibilidades diferentes;</p><p>! minimizar o tempo:</p><p>■ deve-se buscar executar o menor número possível de testes.</p><p>□ Existem algumas técnicas diferentes que ajudam na</p><p>seleção dos casos de teste.</p><p>Fundamentos de Engenharia de Software</p><p>Pequeno Exercício</p><p>□ Um programa lê três inteiros. Esses três valores</p><p>são interpretados como os comprimentos dos lados</p><p>de um triângulo. O programa imprime uma</p><p>mensagem que indica se o triângulo é escaleno,</p><p>isósceles ou equilátero.*</p><p>! Qual é o conjunto de casos de</p><p>teste que você considera</p><p>necessário executar para</p><p>verificar esse programa?</p><p>* Extraído de Glenford J. Myers, The Art of Software Testing,</p><p>Willey Interscience, 1979.</p><p>Fundamentos de Engenharia de Software</p><p>Pequeno Exercício – Alguns Casos de</p><p>Teste</p><p>1. Você tem um caso de teste que representa um triângulo</p><p>escaleno válido?</p><p>! Note que casos de testes como 1,2,3 ou 2,5,10 não ganham um</p><p>“sim” nesta pergunta;</p><p>■ não existem triângulos com estes lados.</p><p>2. Você tem um caso de teste que representa um triângulo</p><p>equilátero válido?</p><p>3. Você tem um caso de teste que representa um triângulo</p><p>isósceles válido?</p><p>! Um caso de teste como 2,2,4 não pode ser contado.</p><p>4. Você tem, no mínimo, três casos de testes que representam</p><p>um triângulo isósceles válido para os quais você tenha</p><p>tentado as três permutações possíveis?</p><p>! Como 3,3,4; 3,4,3; 4,3,3.</p><p>Fundamentos de Engenharia de Software</p><p>Pequeno Exercício – Alguns Casos de</p><p>Teste</p><p>5. Você tem um caso de teste no qual um dos lados é zero?</p><p>6. Você tem um caso de teste no qual todos os lados são</p><p>iguais a zero?</p><p>7. Você tem um caso de teste no qual um dos lados tem o</p><p>valor negativo?</p><p>8. Você tem um caso de teste com três inteiros maiores que</p><p>zero, onde a soma de dois lados é igual ao terceiro</p><p>lado?</p><p>! Se o programa disser que 1,2,3 representa um triângulo escaleno;</p><p>■ ele contém um erro.</p><p>9. Você tem, no mínimo, três casos de teste da categoria 8</p><p>para os quais você tentou as três permutações?</p><p>! Como 1,2,3; 1,3,2 e 3,1,2.</p><p>Fundamentos de Engenharia de Software</p><p>Pequeno Exercício – Alguns Casos de</p><p>Teste</p><p>10. Você tem um caso de teste com três inteiros maiores</p><p>que zero, onde a soma de dois lados é menor que o</p><p>terceiro lado?</p><p>! Como 1,2,4 ou 12,15,30.</p><p>11. Você tem, no mínimo, três casos de teste da categoria 10</p><p>para os quais você tentou as três permutações?</p><p>! Como 1,2,4; 1,4,2 e 4,1,2.</p><p>12. Você tem um caso de teste especificando valores não-</p><p>inteiros?</p><p>13. Você tem um caso de teste especificando uma quantidade</p><p>errada de valores de entrada?</p><p>! Como dois ou quatro, ao invés de três inteiros.</p><p>Fundamentos de Engenharia de Software</p><p>Pequeno Exercício – Discussão</p><p>□ Como ponto de referência:</p><p>! programadores altamente experientes obtêm, em</p><p>média, somente 7,8 pontos do total de 13.</p><p>□ Mesmo o teste de um programa trivial como esse;</p><p>! não é uma tarefa fácil.</p><p>□ Um conjunto de casos de teste que satisfaça às</p><p>condições anteriores;</p><p>! pode revelar a presença de erros;</p><p>! não garante que todos os erros</p><p>possíveis foram</p><p>encontrados;</p><p>! nem a ausência de defeitos no software.</p><p>Fundamentos de Engenharia de Software</p><p>Níveis de Teste</p><p>teste de unidade teste de integração</p><p>teste de validação/</p><p>aceitaçãoteste de sistema</p><p>Fundamentos de Engenharia de Software</p><p>Teste de Unidade</p><p>□ Testa cada componente de software individualmente;</p><p>! verificando se ele funciona adequadamente como uma</p><p>unidade.</p><p>□ Verifica a implementação do componente de</p><p>software testado.</p><p>□ Componente de software:</p><p>! classe, método, procedimento, etc.</p><p>□ Aplicação de técnicas de teste caixa-branca.</p><p>□ Automatizado.</p><p>□ Especificado, desenhado, implementado e executado pelo</p><p>próprio desenvolvedor.</p><p>Fundamentos de Engenharia de Software</p><p>Teste de Integração</p><p>□ Envolve diversos componentes;</p><p>! interagindo entre si.</p><p>□ Verifica as interfaces entre os</p><p>componentes de uma arquitetura.</p><p>□ Aplicação predominante de técnicas de teste</p><p>caixa-preta.</p><p>! Uma quantidade limitada de testes caixa-branca</p><p>pode ser usada;</p><p>■ para garantir a cobertura dos principais caminhos de</p><p>controle.</p><p>Fundamentos de Engenharia de Software</p><p>Teste de Regressão</p><p>□ Alterações em unidades;</p><p>! causam modificações no comportamento da</p><p>unidade alterada;</p><p>! podem causar modificações no comportamento de</p><p>outras unidades também;</p><p>■ por causa dos efeitos colaterais.</p><p>□ Em ambos os casos, quando as unidades</p><p>afetadas pelas alterações já haviam sido</p><p>previamente testadas;</p><p>! sugere-se a execução de testes de regressão.</p><p>Fundamentos de Engenharia de Software</p><p>Teste de Regressão</p><p>□ Reexecução de algum subconjunto de testes que</p><p>já haviam sido conduzidos anteriormente;</p><p>! para detectar o surgimento de defeitos que antes</p><p>não existiam;</p><p>! para checar se eles continuam funcionando de</p><p>maneira apropriada.</p><p>□ São usados:</p><p>! na fase de integração;</p><p>! na fase de manutenção.</p><p>□ Emprego de ferramentas de automatização de</p><p>testes.</p><p>Fundamentos de Engenharia de Software</p><p>Teste de Aceitação</p><p>□ Visa demonstrar que o sistema realiza</p><p>suas tarefas conforme o esperado.</p><p>□ Valida o comportamento do sistema;</p><p>!de acordo com a especificação de</p><p>requisitos;</p><p>■ funcionais e não-funcionais.</p><p>□ Aplicação de técnicas de teste caixa-</p><p>preta.</p><p>Fundamentos de Engenharia de Software</p><p>Teste de Sistema</p><p>□ Envolve o sistema como um todo;</p><p>!ou algum subsistema independente.</p><p>□ Exercita o sistema como um todo;</p><p>!validando a integração de todos os</p><p>elementos, como:</p><p>■ software;</p><p>■ hardware;</p><p>■ pessoas;</p><p>■ informação.</p><p>Fundamentos de Engenharia de Software</p><p>Teste de Sistema</p><p>□ Teste de Segurança:</p><p>! valida os mecanismos de proteção incorporados</p><p>ao sistema;</p><p>■ que devem impedir acessos impróprios.</p><p>□ Teste de Estresse:</p><p>! projetado para submeter o sistema a situações</p><p>anormais de demanda por recursos.</p><p>□ Teste de Desempenho:</p><p>! valida o desempenho do sistema como um todo.</p><p>Fundamentos de Engenharia de Software</p><p>Testes e Depuração</p><p>□ São processos distintos.</p><p>□ Testes preocupam-se com a identificação de</p><p>defeitos em um software.</p><p>□ Depuração ocupa-se com a localização e</p><p>reparo desses defeitos.</p><p>□ Depuração envolve formular hipóteses sobre</p><p>o comportamento do software;</p><p>! e testar essa hipótese para encontrar o erro no</p><p>sistema.</p><p>Fundamentos de Engenharia de Software</p><p>Depuração: um Processo de</p><p>Diagnóstico</p><p>Fundamentos de Engenharia de Software</p><p>O Processo de Depuração</p><p>casos de teste</p><p>resultados</p><p>causas</p><p>suspeitas</p><p>causas</p><p>identificadas</p><p>correções</p><p>testes de</p><p>regressão</p><p>novos</p><p>casos</p><p>de teste</p><p>Depuração</p><p>Fundamentos de Engenharia de Software</p><p>O Esforço de Depuração</p><p>tempo requerido</p><p>para identificar</p><p>o sintoma e</p><p>determinar</p><p>a causa</p><p>tempo requerido</p><p>para corrigir um</p><p>erro e conduzir</p><p>testes de</p><p>regressão</p><p>Fundamentos de Engenharia de Software</p><p>Sintomas e Causas</p><p>sintoma</p><p>causa</p><p>□ O sintoma pode ser</p><p>intermitente.</p><p>□ O sintoma e a causa podem</p><p>estar geograficamente</p><p>separados.</p><p>□ O sintoma pode desaparecer;</p><p>! quando um outro problema é</p><p>consertado.</p><p>□ A causa pode ser uma</p><p>combinação de fatores.</p><p>□ A causa pode ser devido a uma</p><p>premissa errada;</p><p>! que todos acreditam.</p><p>Fundamentos de Engenharia de Software</p><p>Referências</p><p>□ MYERS, Glenford. The art of software</p><p>testing, John Willwey & Sons, 1979. Capítulos</p><p>1 e 2.</p><p>□ BURNSTEIN, Ilene. Practical software</p><p>testing, a process-oriented approach.</p><p>Springer, 2003.</p><p>□ PFLEEGER, Shari Lawrence. Engenharia de</p><p>software: teoria e prática. Capítulos 8 e 9.</p><p>2a edição.</p><p>Fundamentos de Engenharia de Software</p><p>Referências</p><p>□ SOMMERVILLE, Ian. Engenharia de</p><p>software. Capítulo 8. 9a edição.</p><p>□ PRESSMAN, Roger S. Engenharia de</p><p>software. Capítulos 16 e 20. 8a edição.</p><p>□ PAULA-FILHO, Wilson de Pádua. Engenharia</p><p>de software: fundamentos, métodos e</p><p>padrões. Capítulo 9. 3a edição.</p>