1 / 55

Teste de Software Parte 4

Teste de Software Parte 4. Ricardo de Almeida Falbo Tópicos Especiais – Qualidade de Software 2008/2 Departamento de Informática Universidade Federal do Espírito Santo. Agenda. Teste de Integração Teste de Classe Teste de Interação Teste de Componente Teste de Caso de Uso

leann
Download Presentation

Teste de Software Parte 4

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Teste de SoftwareParte 4 Ricardo de Almeida Falbo Tópicos Especiais – Qualidade de Software 2008/2 Departamento de Informática Universidade Federal do Espírito Santo

  2. Agenda • Teste de Integração • Teste de Classe • Teste de Interação • Teste de Componente • Teste de Caso de Uso • Teste Baseado em Máquina de Estados • Teste de Sistema Tópicos Especiais - Qualidade de Software 2008/2

  3. Teste de Integração • Objetivo: verificar se as partes, quando colocadas para trabalhar juntas, não conduzem a erros. • Todas as técnicas de teste se aplicam, com destaque para o teste funcional. • Questão importante: Como agrupar os módulos para se testar a integração entre eles? • No paradigma procedimental (Pressman, 2006): • Integração não incremental (big-bang) • Integração Ascendente (bottom-up) • Integração Descendente (top-down) • E no paradigma OO? Tópicos Especiais - Qualidade de Software 2008/2

  4. Teste de Integração OO • Níveis de Teste de Integração: • Teste de Classe: testa a interação entre métodos de uma classe, usando o conjunto de atributos de uma instância. • Teste de Interação ou Interclasse: testa a colaboração / interação entre classes. Inicia-se sem prover ainda uma funcionalidade completa, avançando para a interação no contexto de um componente ou caso de uso. Tópicos Especiais - Qualidade de Software 2008/2

  5. Teste de Integração OO • Teste de Componente: Quando um componente é implementado usado a tecnologia de objetos, ele pode ser visto como um conjunto de classes que provê uma porção significativa de funcionalidade, acessível por meio de um conjunto de interfaces especificando os comportamentos disponíveis. • Perspectiva do desenvolvedor de componente: testa a colaboração entre classes que compõem um componente, bem como as suas interfaces contratuais públicas. Técnicas funcionais e estruturais podem ser aplicadas, pois o código-fonte está disponível. • Perspectiva do cliente de componente: quando um componente desenvolvido independentemente é integrado a uma aplicação, o código pode não estar disponível, dificultando a atividade de teste. Neste caso, apenas critérios funcionais são aplicáveis. Tópicos Especiais - Qualidade de Software 2008/2

  6. Teste de Integração OO • Teste de Caso de Uso: testa a colaboração entre classes no contexto de um caso de uso ou fluxo de eventos de um caso de uso. • Teste de Subsistema: testa partes de um sistema, contendo vários componentes e realizando vários casos de uso. Tópicos Especiais - Qualidade de Software 2008/2

  7. Teste de Classe • Visto como um teste de integração, o teste de classe visa testar a integração de métodos e atributos de uma classes. • Aspecto importante a verificar: restrições na ordem de invocação de suas operações (muitas vezes implícitas) estão sendo satisfeitas? • Seqüência mínima de teste: aquele que exercita o histórico de vida comportamental mínimo de um objeto da classe. • Além da seqüência mínima, há muitas combinações possíveis de invocação de operações (Pressman, 2006). Tópicos Especiais - Qualidade de Software 2008/2

  8. Teste de Classe • Seja a seguinte classe Conta. • Qual a seqüência de testes mínima a ser feita? • Que outros casos de teste são possíveis? Tópicos Especiais - Qualidade de Software 2008/2

  9. Teste de Classe • Seqüência Mínima • abrir – estabelecerLimite – depositar – retirar – encerrar • Outros casos de teste possíveis: Infinitos... • Seqüências Válidas • abrir – estabelecerLimite – depositar – [obterLimite | estabelecerLimite | depositar | retirar | obterSaldo | obterExtrato]n – retirar – encerrar • Seqüências Inválidas • estabelecerLimite – depositar – retirar – encerrar • abrir – depositar – retirar – encerrar • abrir – estabelecerLimite – retirar – encerrar • abrir – estabelecerLimite – depositar – encerrar • abrir – estabelecerLimite – depositar – retirar – encerrar - depositar • etc Tópicos Especiais - Qualidade de Software 2008/2

  10. Teste de Classe • Necessidade de reduzir o número de casos de teste • Teste Aleatório ou Randômico • Casos de teste para diferentes seqüências (normalmente válidas) de operações são gerados aleatoriamente. • Teste de Partição no Nível de Classe • Análogo ao critério Particionamento de Equivalência. • Casos de teste são projetados para exercitar cada categoria (válida ou inválida). • Alguns critérios: • Partição Baseada em Estado • Partição Baseada em Atributo • Partição Baseada em Categoria Tópicos Especiais - Qualidade de Software 2008/2

  11. Partição Baseada em Estado • O termo “estado” neste contexto designa o estado interno de um objeto dado pelo seu conjunto de atributos e não apenas os estados definidos por uma máquina de estados da classe. • Categoriza as operações em duas grandes classes: • operações que podem mudar o estado de um objeto da classe, ou seja, que alteram o valor de atributos da classe e • operações que não podem mudar o estado de um objeto da classe. Tópicos Especiais - Qualidade de Software 2008/2

  12. Partição Baseada em Estado • Casos de teste são projetados de modo a exercitarem separadamente as operações que mudam o estado e aquelas que não mudam o estado (Pressman, 2006). • A seqüência mínima de teste é usada como base. • Introduzem-se operações da partição nessa seqüência, respeitando a ordem da seqüência mínima, para gerar casos de teste com seqüências válidas. Tópicos Especiais - Qualidade de Software 2008/2

  13. Partição Baseada em Estado • Seja a seguinte classe Conta. • Que operações mudam o estado? • Que casos de teste considerar? Tópicos Especiais - Qualidade de Software 2008/2

  14. Partição Baseada em Estado • Operações que mudam o estado: • estabelecerLimite, depositar, retirar • Operações que não mudam o estado: • obterLimite, obterSaldo, obterExtrato • Seqüência Mínima • abrir – estabelecerLimite – depositar – retirar – encerrar • Partições Válidas: • abrir – estabelecerLimite – depositar – [estabelecerLimite | depositar | retirar ]n–retirar – encerrar • abrir – estabelecerLimite – depositar – [obterLimite | obterSaldo | obterExtrato]n–retirar – encerrar Tópicos Especiais - Qualidade de Software 2008/2

  15. Partição Baseada em Atributo • Categoriza as operações com base nos atributos que elas usam (Pressman, 2006): • Operações que usam o atributo sem modificá-lo • Operações que modificam o valor do atributo • Operações que não usam o atributo Tópicos Especiais - Qualidade de Software 2008/2

  16. Partição Baseada em Atributo • Seja a seguinte classe Conta. • Que operações usam / modificam / não usam cada um dos atributos? Tópicos Especiais - Qualidade de Software 2008/2

  17. Partição Baseada em Atributo • Atributo limiteCredito • Usam: obterLimite, obterSaldo, obterExtrato, retirar • Modificam: estabelecerLimite • Não usam ou modificam: abrir, depositar, encerrar • Atributo saldo • Usam: obterSaldo, obterExtrato, encerrar • Modificam: abrir, depositar, retirar • Não usam ou modificam: estabelecerLimite, obterLimite • Casos de Teste: pelo menos um caso de teste dentro de cada uma das partições. Tópicos Especiais - Qualidade de Software 2008/2

  18. Partição Baseada em Categoria • Categoriza as operações com base na função genérica que cada uma realiza. • Por exemplo, uma categorização que estende a partição baseada em estado: • Operações de inicialização • Operações de consulta (que não alteram o estado da classe) • Operações com atribuição (que alteram o estado da classe) • Operações de término Tópicos Especiais - Qualidade de Software 2008/2

  19. Partição Baseada em Categoria • Operações de inicialização: • abrir • Operações de consulta: • obterLimite • obterSaldo • obterExtrato • Operações de atribuição: • estabelecerLimite • depositar • retirar • Operações de término: • encerrar Tópicos Especiais - Qualidade de Software 2008/2

  20. Teste de Classe • Para cada classe, é importante definir se a mesma deve ser testada de forma separada ou no contexto de uma parte maior do sistema (p.ex., componente, caso de uso etc). • Essa definição deve baseada nos seguintes fatores (McGregor e Sykes, 2001): • Papel da classe no sistema (criticidade) e risco associado à mesma • Complexidade da classe, medida em termos do número de estados, operações e associações com outras classes • Esforço associado com o desenvolvimento do driver de teste da classe. Tópicos Especiais - Qualidade de Software 2008/2

  21. Planejamento de Teste de Classe • Quem deve testar? • Geralmente, classes são testadas pelos próprios desenvolvedores, sendo que seu plano de teste pode ser feito por outra pessoa. • Vantagens: • Minimiza o número de pessoas que devem conhecer a especificação da classe. • Facilita a implementação dos casos de teste, pois o testador conhece a implementação da classe. • Driver de teste pode ser usado para depuração. • Desvantagens: • Problemas no entendimento da especificação são propagados para o teste (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

  22. Planejamento de Teste de Classe • O que testar? • Basicamente, deseja-se testar se uma implementação reflete exatamente sua especificação e nada além disso. • O esforço para testar se a implementação contém apenas o que foi especificado pode ser alto e, portanto, deve ser avaliado em relação ao risco associado à classe. • Se após a execução de vários de casos de teste, ainda há código não coberto, é possível que exista comportamento indesejado na classe (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

  23. Planejamento de Teste de Classe • Quando testar? • Assim que uma classe está pronta para ser codificada, seu plano de teste pode ser elaborado. • O teste de uma classe deve ser executado antes que a mesma seja usada em outras partes do software. • Caso a implementação mude, os testes devem ser executados novamente podendo ser alterados ou não (quando não alterados, está-se aplicando teste de regressão) (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

  24. Planejamento de Teste de Classe • Como testar? • Classes são testadas através de drivers de teste, construindo o ambiente necessário à execução dos casos de teste (McGregor e Sykes, 2001). • Uso de ferramentas pode ajudar, aumentando a produtividade do teste de classe. Tópicos Especiais - Qualidade de Software 2008/2

  25. Planejamento de Teste de Classe • Quanto testar? • Avaliar criticidade e riscos associados à classe (relação custo-benefício) (McGregor e Sykes, 2001). • Aplicar técnicas de teste de classe para minimizar o número de casos de teste, mas com uma boa cobertura. Tópicos Especiais - Qualidade de Software 2008/2

  26. Plano de Teste de Classe • Nome da Classe: • Desenvolvedor: • Testador: • Criticidade: • Seqüência Mínima: • Considerações sobre o Projeto da Suíte de Teste • Casos de Teste (organizados por tipo) • Resultados • Considerações sobre a Cobertura da Suíte de Teste Tópicos Especiais - Qualidade de Software 2008/2

  27. Teste de Interação ou Interclasse • Uma interaçãoé uma requisição feita por um objeto (o transmissor) a outro (o receptor) para executar uma das operações do receptor. • Um programa OO consiste de uma coleção de objetos que colaboram para resolver um problema. • Assim, a correta colaboração (ou interação) entre objetos em um programa OO é crítica para a correção do programa (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

  28. Formas Típicas de Interação entre Classes • Mensagens passadas a outros objetos. • Uma operação pública que recebe como parâmetro um ou mais objetos. • Uma operação pública que retorna um objeto. • Objeto que mantém uma referência a outro como parte de seus atributos (atributo implementando uma associação). • Um método de uma classe que cria uma instância de outra classe como parte de sua implementação (muitas vezes, um objeto temporário). Tópicos Especiais - Qualidade de Software 2008/2

  29. Teste de Interação • Como testar? • Usando classes de teste • Usando o próprio programa de aplicação (p.ex., caso de uso + estrutura de acesso ao caso de uso) • Teste funcional é o mais usado, mas observar o código pode ser importante para definir o que testar (para identificar quais formas de interação estão presentes e entre quais classes). • Questão: Como agrupar classes para testar sua integração? Tópicos Especiais - Qualidade de Software 2008/2

  30. Estratégia de Integração Baseada no Uso • Adaptação para o paradigma OO da estratégia ascendente de integração. • Começa testando as classes servidoras ou primitivas, i.e., as classes que não usam outras classes. • Depois de testar as classes primitivas, testam-se as classes dependentes (ou não primitivas) que dependem apenas das classes já testadas e assim sucessivamente. Tópicos Especiais - Qualidade de Software 2008/2

  31. Teste Baseado no Caminho de Execução • Integra o conjunto de classes necessárias para responder a uma entrada ou um evento do sistema. • Cada caminho de execução é testado e integrado individualmente. • Teste de Componente e Teste de Caso de Uso se enquadram nesta estratégia. Tópicos Especiais - Qualidade de Software 2008/2

  32. Teste de Interação • Testes de interação baseados apenas nas especificações de operações públicas são consideravelmente mais diretos que os baseados nas implementações das mesmas. • Quando a abordagem baseada no uso é aplicada integralmente, são necessários apenas testes baseados nas especificações de operações públicas. • Quando algumas das classes não são testadas individualmente, contudo, tais testes podem não ser suficientes (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

  33. Abordagem de Projeto e Teste • A abordagem de projeto (design) adotada tem grande influência no projeto de casos de teste. • Ex.: Criação de objetos: teste na interface, aplicação ou domínio? • É possível classificar as abordagens de projeto em duas grandes categorias: • Abordagem defensiva: assume que pouca ou nenhuma checagem de valores de parâmetros vai ocorrer antes das mensagens serem enviadas para objetos da classe. • Abordagem de projeto por contrato: assume que as pré-condições são checadas antes que a mensagem seja enviada e que a mensagem não é enviada se os parâmetros estão fora dos limites aceitáveis (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

  34. Abordagem Defensiva de Projeto • Poucas pré-condições estabelecidas. • Necessidade de muitas checagens internas de violação de restrições sobre atributos. • Muitos resultados possíveis (sobretudo de exceção). • Necessidade de um maior número de casos de teste nas classes que recebem mensagens, de modo a checar valores de entrada que produzem exceções e, por conseguinte, maior esforço no teste de classe (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

  35. Abordagem de Projeto por Contrato • Muitas pré-condições estabelecidas. • Pouca ou nenhuma checagem interna de violação de restrições sobre atributos. • Poucos resultados possíveis (especialmente de exceção). • Necessidade de um maior número de casos de teste nas classes que enviam mensagens, de modo a checar valores de entrada que produzem exceções e, por conseguinte, maior esforço no teste de interação (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

  36. Teste de Componente: Perspectiva de Desenvolvedor de Componentes • Um componente pode ser visto como um agregado de objetos e, portanto, o teste de componentes é muito similar ao teste de interações entre conjuntos de objetos. • Um componente é tipicamente maior do que uma classe e, por conseguinte, é mais difícil obter boa cobertura de código usando um critério funcional baseado na especificação do componente (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

  37. Teste de Caso de Uso • Testa a interação no contexto da realização de um caso de uso. • O que testar? Testar as partes mais usadas e mais críticas com um alcance mais amplo de entradas do que as partes menos usadas e menos críticas. • Perfil de uso: classificação dos casos de uso baseada em uma combinação de freqüência e criticidade. • Riscos associados ao caso de uso devem ser levados em conta e estão fortemente relacionados à criticidade do caso de uso (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

  38. Exemplo: Ferramenta GeRis Tópicos Especiais - Qualidade de Software 2008/2

  39. Exemplo: Ferramenta GeRis Tópicos Especiais - Qualidade de Software 2008/2

  40. Teste de Caso de Uso • Um caso de uso contém um conjunto de fluxos de eventos, incluindo cursos normais, alternativos e de exceção. • Cada fluxo de eventos inclui a ação tomada por um ator e a resposta produzida pelo sistema. Esses dois elementos correspondem às partes básicas de um caso de teste de caso de uso. • Para a construção de um caso de teste, valores específicos de entrada são definidos, assim como os correspondentes resultados esperados. • Selecionando diferentes valores para um fluxo de eventos, dá-se origem a diferentes casos de teste (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

  41. Teste de Caso de Uso • Partições de Equivalência podem ser criadas, levando-se em consideração fluxos de eventos normais, alternativos e de exceção. • Para cada caso de uso / fluxo de exceção: • Identificar os valores que devem ser informados pelo ator. • Identificar partições de equivalência para cada entrada. • Construir tabelas de combinações de valores das várias partições de equivalência. • Construir casos de teste exercitando essas combinações (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

  42. Exemplo: Ferramenta GeRis Tópicos Especiais - Qualidade de Software 2008/2

  43. Exemplo: Ferramenta GeRis Tópicos Especiais - Qualidade de Software 2008/2

  44. Exemplo: Ferramenta GeRis Tópicos Especiais - Qualidade de Software 2008/2

  45. Exemplo: Ferramenta GeRis Tópicos Especiais - Qualidade de Software 2008/2

  46. Exemplo: Ferramenta GeRis Tópicos Especiais - Qualidade de Software 2008/2

  47. Teste Baseado em Máquina de Estados • Uma máquina de estados especifica as seqüências de estados pelos quais um objeto passa durante seu tempo de vida em resposta a eventos, juntamente com as respostas a esses eventos (Booch et al., 2006). • Pela definição acima, testes baseados em uma máquina de estados aplicam-se a uma classe e, portanto, podem ser vistos como um tipo de teste de classe. Isso é verdade sobretudo quando um diagrama de estados é elaborado na fase de projeto, com as transições entre estados correspondendo a métodos da classe. Tópicos Especiais - Qualidade de Software 2008/2

  48. Teste Baseado em Máquina de Estados • Quando um diagrama de estados da fase de análise é usado como base para o teste, muitas vezes, as transições correspondem a fluxos de eventos de casos de uso. Assim, é necessário que cada um desses fluxos de eventos tenha sido testado e integrado. • Nesta visão, um teste baseado em máquina de estados visa testar a integração de vários casos de uso, tendo como foco uma classe. Tópicos Especiais - Qualidade de Software 2008/2

  49. Teste Baseado em Máquina de Estados • Usar o diagrama de estados para determinar a seqüência de eventos a serem exercitados. • Os casos de teste devem cobrir todos os estados. • Cada uma das transições deve ser exercitada pelo menos uma vez. • Eventos inválidos devem ser testados para ver se o sistema refuta a sua ocorrência. Tópicos Especiais - Qualidade de Software 2008/2

  50. Teste de Subsistema • Após testar casos de uso isoladamente ou no contexto de uma máquina de estados, pode ser útil, ainda, testar se os vários casos de uso se comportam adequadamente no contexto de um subsistema. • Testes de ciclo de vida do domínio: realizar os processos de negócio (casos de uso) como eles tipicamente acontecem (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

More Related