Cct0204_livro_1479

Estácio\nDisciplina: TESTES DE SOFTWARE\n\nEngenharia de Software\n6ª Edição/2006\nRoger S. Pressman\nCapítulos\n- Estratégias de Teste de Software\n- Táticas de Teste de Software\n- Teste de Aplicação da Web\n- Gestão de Qualidade\n\nMcGraw-Hill\nwww.armed.com.br\nISBN 9788566804571 CAPÍTULO 13\nEstratégias de Teste de Software\n\nConceitos-Chave\n\nUma estratégia de teste de software integra métodos de projeto de casos de teste em uma série bem planejada de passos, que resultam na construção bem-sucedida de software. A estratégia fornece um roteiro que descreve os passos a ser conduzidos como parte do teste, quando esses passos são planejados e executados, e quanto de esforço, tempo e recursos serão necessários. Assim, qualquer execução de teste deve incorporar planejamento de teste, projeto de casos de teste, execução de teste e a resultante coleta e avaliação de dados.\nUma estratégia de testes de software deve ser suficientemente flexível para promover uma abordagem de teste sob medida. Ao mesmo tempo, deve ser suficientemente rígida para promover planejamento adequado e acompanhamento gerencial, a medida que o projeto vai progredir. Shooman [SH03] discute esses aspectos:\n\nSob vários aspectos, o teste é um processo independente e o número de tipos diferentes de teste varia conforme as necessidades abrangentes do desenvolvimento. Durante muitos anos, nossa linha de ação consistia em ceder aos problemas de programação e ao código cuidadoso e à inteligência própria da programação. Estamos agora em um ponto em que estamos testando o software para satisfazer necessidades e aumentar a qualidade do código. CAPÍTULO 13\nEstratégias de Teste de Software\n\nUma Abordagem Estratégica ao Teste de Software\nTeste é um conjunto de atividades que podem ser planejadas antecipadamente e conduzidas sistematicamente. Por essa razão, um gabarito para teste de software—um conjunto de passos nos quais podemos incluir três principais funções de projeto de teste e métodos de teste específicos— deve ser definido para o processo de software. O teste de sistemas críticos e objetos reais é discutido no Capítulo 23. Neste capítulo, concentramos nossas atenções na estratégia de teste. Todos fazem ao desenvolver estratégias de teste e esses aspectos características principais.\n\nPara realizar teste efetivo, uma equipe de software deve conduzir revisões técnicas formais (Capítulo 26). Ao fazer isso, precisamos ser eliminados.\nO teste começa no nível de componente e prossegue “para fora”, em direção à integração de todo o sistema baseado em computador. Diferentes técnicas de testes são adequadas em diferentes momentos. É teste e condução de pelo menos um número de conjuntos de modos.\n\nO teste de software é um elemento de um aspecto mais amplo... 290 PARTE DOIS PRÁTICA DE ENGENHARIA DE SOFTWARE \"Testar é uma parte invisível do equilibra esforço responsável por desenvolver um sistema de software.\" William Howden O teste oferece efetivamente o último reduto no qual a qualidade pode ser avaliada e, mais pragmaticamente, erros podem ser descobertos. Mas o teste não deve ser encarado como medio de proteção. Como sabemos bem dizer, \"você não pode testar a qualidade. Se ela não está lá você não pode tentar testar; ela não estará lá quando tentar testar\". A qualidade é incorporada ao software durante o processo de engenharia de software. À aplicação de ferramentas, revisões técnicas formais eficazes e gerência e medição sólidas, todos levam à qualidade de confirmação do teste. Maillier (ML71) relaciona o teste de software à garantia de qualidade, afirmando que \"a motivação subjacente ao teste de programa é afirmar a qualidade do software com métodos que podem ser aplicados econômica e efetivamente tanto a sistemas de grande porte.\" 13.1.2 Organização do Teste de Software Em cada projeto de software há um conflito de interesses inerente que ocorre quando este começa, o pessoal que construiu o software agora solicita o teste. Isso parece íncubo em si mesmo; afinal de contas, quem concebeu o programa deveria fazer o teste. No entanto, esses mesmos desenvolvedores têm um interesse oculto em demonstrar que o programa está livre de erros, que funciona de acordo com os requisitos do cliente e que foi codificado de acordo com o cronograma e dentro do orçamento. Cada um desses interesses se contrapõe a um teste rigoroso. \"Otimizando o risco ocupacional do programador, frente a o treinamento.\" Kent Beck Do ponto de vista psicológico, a análise e o projeto de software (juntamente com a codificação) é, em essência, uma área de tentativas. O teste exige uma abordagem haja um desafio; há uma tentativa, e esta, uma vez definida, é de \"quebrar\" a coisa que engenheiro de software construiu. Do ponto de vista do construtor, o teste pode ser considerado (psicologicamente) destrutivo. Assim, o construtor segue suavemente, propiciando e executando testes que se demonstrem o que o programa funciona, em vez de descobrir erros. Infelizmente, erros estarão presentes. E, se o engenheiro de software não os achar, e o cliente achar! Há frequentemente algumas confusões provocadas que podem ser erroneamente inferidas dessas discussões: (1) que o desenvolvedor de software não deve fazer nenhum teste; (2) que o software deve ser \"jogado como um muro\"; para estranhos que vão testá-lo independentemente; (3) que os testadores se envolveram com o projeto apenas quando os passos de teste estão para começar. Cada uma dessas afirmações é incorreta. O desenvolvedor de software é sempre responsável por testar as unidades individuais (componentes) do programa garantindo que cada unidade realiza a função ou execução e comportamento para o qual foi projetada. Em muitos casos, o desenvolvedor também cuida testes de integração — um passo de teste que leva à construção (e à arquitetura completa do software. Apenas após a arquitetura do software ser completada, um grupo independente de teste começa a ser envolvido. O papel do grupo independente de teste (independentemente) é remover os conflitos internos associados com a maneira de construir testar a coisa que construiu. O teste independente remove o conflito de interesses que pode, de outra forma, estar presente. Afinal de contas, o pessoal de ITG é pago para encontrar erros. No entanto, a engenheira de software não entrega o programa ao ITG e se retira. O desenvolvedor e o ITG trabalham juntamente durante um projeto de software para garantir que testes rigorosos sejam conduzidos. Durante a condução do teste, o desenvolvedor deve estar disponível para corrigir os erros eventualmente descobertos. 291 CAPÍTULO 13 ESTRATÉGIAS DE TESTE DE SOFTWARE \"O primeiro erro que a pessoa comete é pensar que a equipe de teste é responsável pela garantia da qualidade.\" Bryan Merick O ITG é parte da equipe do projeto de desenvolvimento de software no sentido de que envolvido durante a análise e o projeto e continua envolvido planejando e especificando procedimentos de teste ao longo de um projeto de grande porte. No entanto, em muitos casos, o ITG pertence à organização de garantia da qualidade de software, alcançando assim um grau de independência que poderia não ser possível se ele fizesse parte da organização de engenharia de software. O processo de engenharia de software pode ser visto como a resultado ilustrada na Figura 13.1. Inicialmente, a engenharia de sistemas define e pode se aventurar a analisar os requisitos de software, em que são estabelecidos o domínio da informação, a função, o comportamento, o desempenho, as restrições e os critérios de validação para o software. Movendo-se ao longo, espiral, abrangendo projeto e finalmente a codificação. Para perceber suavemente os erros, novos mecanismos podem ser apresentados, usando de rotas que diminuem o nível abstraído com cada volta. Uma estratégia para teste de software deve sempre ser vista no contexto de espiral (Figura 13.1). O teste de unidade, até neste contexto, envolve a entrega do software para longo da espiral de teste e, uma vez que um foco fino no coletivo que leva a projeção, em relação, em que os requisitos em seus estudos de artificalização, que os componentes devem ser montados em integrados para formar o pacote de software completo. O teste de integração cuida dos tópicos associados com os problemas duales de verificação e construção de programas. As técnicas de projeto de casos de teste que enfocam as entradas e saídas são mais prevalentes durante a integração, apesar de as técnicas que exercitam caminhos específicos do programa poderão ser usadas para garantir a cobertura dos principais caminhos de controle. Depois que o software tiver sido integrado (construído), um conjunto de testes de alto nível é conduzido. Crítérios de validação (estabelecidos durante a análise de nível. 292 PARTE DOIS PRÁTICA DE ENGENHARIA DE SOFTWARE requisitos) precisam ser avaliados. Os testes de validação fornecem garantia final de que o software satisfaz a todos os requisitos funcionais, comportamentais e de desempenho. O último passo de teste de alto nível avança fora dos limites da engenharia de software no contexto mais amplo da engenharia de sistemas de computação. O software, uma vez validado, deve ser combinado com os outros elementos do sistema por exemplo, o hardware, o pessoal, os bancos de dados. O teste de sistema verifica se todos os elementos combinam adequadamente e se a função/desempenho global do sistema é alcançada. 13.1.4 Uma Estratégia de Teste de Software para Arquiteturas Orientadas a Objetos O teste de sistemas orientados a objetos apresenta um conjunto diferente de desafios para o engenharia de software. A definição do teste deve ser ampliada para incluir técnicas de descobrimento que sejam focadas em aspectos ou várias que são aplicadas a modelos de análise e projeto. A complexidade e a constituição de representações do sistema precisam ser avaliadas à medida que cada classe constrói o sistema. O teste é entendido como parte do que significa o estereótipo de integração mudam significativamente. Em resumo, tanto as estratégias de teste quanto as táticas de teste (Capítulo 14) devem levar em conta as características singulares de software orientado a objetos. A conversa:\nDoug: Perceber-te que não empregamos tempo suficiente\nfalando sobre teste.\nVinda: Claro, mas todos nós temos estado um pouco\nocupados. Além disso, não revelaremos muito sobre\nnós ou sobre o que estamos pensando.\nDoug (sorrindo): Eh, estou só brincando. Nós fazemos\num bom trabalho.\nShikha: Eu gosto da ideia de prestar testes alaide às\nideias de começar a codificar. Portanto, assim, é isso que eu tenho tentado fazer. Tenho\noutra base comum de ideias para ajudar a entender o\npróprio trabalho do teste.\nJmnie: Então, temos de trabalhar nessa integração.\nDoug (para Vinda): Vamos apenas pegar a programação extrema, \nJulgar mais uma vez que é bastante divertida.\nEd: E, mesmo que não estamos usando Programação\nextrema em si, decidimos que servir uma boa ideia\nprojetar\n\n13.1.5 Crítérios para Complementação do Teste\nUma questão clássica é levantada toda vez que o teste de software é discutido: \"Quando terminamos o teste como sabemos que testamos suficientemente?\" Infelizmente, não há resposta definitiva para essa questão, mas algumas respostas pragmáticas e primeiras tentativas de diretrizes experimentais.\nUma resposta à questão é: Você nunca acaba de testar, a tarefa simplesmente passa de você \npara seu cliente/finalidade. Quando o cliente/finalidade está satisfeito, você está satisfeito em relação ao produto e ao conjunto de erros que agora foram corrigidos nas outras áreas da qualidade de software. Essa não é a única abordagem para determinar quando você deve parar, mas é uma abordagem válida.\n\n13.2 Tópicos Estratégicos\nPosteriormente, neste capítulo, exploraremos uma estratégia sistemática para teste de software re. Mas, mesmo a melhor estratégia falhará se uma série de tópicos importantes não for cuidada. Tom Gilb [Gil.95] alega que os seguintes tópicos merecem atenção, e uma estratégia de teste de software bem-sucedida deve ser implementada:\n\nEspecificar os requisitos do produto de um modo quantificável muito antes do teste começar\n\nApesar do objetivo principal do teste ser encontrar erros, uma boa estratégia do teste também avalia outras características de qualidade tais como probabilidade, mantenibilidade e usabilidade [Capítulo 15]. Essas devem ser especificadas de um modo que sejam mensuráveis, a fim de que os resultados do teste não sejam ambíguos. Explique as exigências do produto de um modo quantificável muito antes de o teste começar. Apesar do objetivo principal do teste ser encontrar erros, uma boa estratégia do teste também\navalia outras características de qualidade tais como probabilidade, mantenibilidade e usabilidade [Capítulo 15]. Essas devem ser especificadas de um modo que sejam mensuráveis, a fim de que os resultados do teste não sejam ambíguos.\n\nExplique explicitamente os objetivos do teste. Os objetivos específicos do teste devem ser enunciados em termos mensuráveis. Por exemplo, a efetividade do teste, a cobertura do teste, e o tempo médio entre falhas, o custo de encontrar e corrigir defeitos, a densidade referente de defeitos devem ser enunciados no plano de teste [Gil.95].\n\nDesenvolva um plano de teste que escreva um perfil para a categoria de usuários. Cada usuário que descobrir um caminho de interação para cada classe de um destino pode reunir os esforços globais de localização do teste no uso real do produto.\n\nDesenvolva um plano de teste que enfrente “teste de código rápido”. [Gilb.95] recomenda que um projeto de engenharia de software deve ser estruturado e construído para buscar um nível alto de agilidade pelo menos em relação ao comportamento no campo. 13.3 Estratégias de Teste para Software Convencional\nHá muitas estratégias que podem ser usadas para teste de software. Em um extremo, uma equipe de software pode esperar até que o sistema esteja totalmente construído e, então, conduza testes no sistema inteiro na esperança de encontrar erros. Essa abordagem, apesar de atraente, simplesmente não funciona. Ela vai resultar em software defeituoso que desabilitou o controle final. No outro extremo, uma engenharia de software pode conduzir testes diretamente, sempre que qualquer parte do sistema seja construída. Essa abordagem, apesar de menos atraente para muitos, pode ser muito efetiva. Infelizmente, a maioria dos desenvolvedores de software hesita em usá-la, o que fazer? Uma estratégia de teste que é escolhida pela maioria das equipes de software leva entre os dois extremos. Essa ajuda uma visão incremental do teste, começando com o teste de unidades do programa, avançando para testes que exercitam o sistema construído. Cada uma dessas classes de teste é descrita nas seções seguintes. Teste nos limites é uma das mais importantes tarefas do teste de unidade. O software frequentemente falha nos seus limites. Isto é, erros ocorrem frequentemente quando o n-ésimo elemento de um vetor de dimensão n é processado, quando a j-ésima rejeição de um ciclo for i/passage é chamado, quando o valor máximo ou mínimo permitido é encontrado. Casos de teste que exercitem estruturas de dados, fluxo de controle e valores de dados indesejadamente alto, indesejavelmente baixo ou máximo e mínimo muito provavelmente descobrirão erros.\n\nUm projeto determina que condições de erros sejam antecipadas e caminhos de manipulação de erros estabelecidos para redirecionar ou claramente terminarem o processamento quando um erro efetivamente ocorre. Youdon (1970) chama essa abordagem de antidotes. Infelizmente, há uma tendência de incluir manipuladores de erros no software que indica a função falsa. A história verdadeira pode servir para ilustrar:\n\nUm sistema de projeto aprovado por computador foi desenvolvido sob contrato. Em um módulo relacionado a transferências, um profissional brilhante colocou a seguinte mensagem de manipulação de erro, depois de uma série de testes condicionais que ativaram vários ramos do teste:\nNÃO HÁ JEITO DE CHEGAR AQUI. Essa \"mensagem tem a função de informar que não há manipulação no sistema do usuário\".\n\nEntre os erros políticos que devem ter sido testados quando a manipulação de erros é avaliada estão: (1) a descrição do tipo de erro; (2) a identificação dos dados encontrados como erro; (3) a condição de erro que intriga a intervenção do sistema antes da manipulação de erro; (4) o processamento do erro e a realização das especificações a partir de uma informação suficiente para a realização da causa do erro.\n\nProcedimentos de teste de unidade. O teste de unidade é normalmente considerado um apêndice no passo de codificação. O projeto de teste de unidade pode ser realizado antes que o código seja escrito ou junto ao projeto do software. O objetivo é que um mapeamento de casos teste tenha uma probabilidade de descobrir erros em dados e nas categorias determinadas. Como um componente não é um componente único, o software para um pseudo controlador nada mais é do que um \"programa principal\", que aciona dados do caso de teste, passa tais dados ao componente e ser testado e imprime os resultados relevantes. Os pseudo controladores servem para substituir módulos que são subordinados (chamados pelo) ao componente a ser testado. Um pseudocontrolado, ou \"pseudo subprograma\", usa a interface dos módulos subordinados, pode fazer um mínimo de manipulação de dados, fornece verificação da entrada e devolve o controle ao módulo que está sendo testado.\n\nPseudocontroladores e pseudocontrolados representam despesas indiretas. Isto é, ambos são softwares que precisam ser escritos (projeto formal não comumente aplicado), mas não são entregues com o produto final do software. Se pseudocontroladores e pseudocontrolados são mantidos bem simples, as despesas indiretas são relativamente baixas. Infelizmente, muitos componentes não podem ser testados no nível de unidade de modo adequado com software adicional \"simples\". Em tais casos, o teste completo pode ser adiado ao passo de teste de integração (em que pseudocontroladores ou pseudocontrolados são também usados).\nO teste de unidade é simplificado quando um componente com alta coesão é projetado. Quando apenas uma função é implementada por um componente, o número de casos de teste é reduzido e os erros podem ser mais facilmente preditos e descobertos.