A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Teste de Software Parte 4 Ricardo de Almeida Falbo Tópicos Especiais – Qualidade de Software 2008/2 Departamento de Informática Universidade Federal do.

Apresentações semelhantes


Apresentação em tema: "Teste de Software Parte 4 Ricardo de Almeida Falbo Tópicos Especiais – Qualidade de Software 2008/2 Departamento de Informática Universidade Federal do."— Transcrição da apresentação:

1 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

2 Tópicos Especiais - Qualidade de Software 2008/22 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

3 Tópicos Especiais - Qualidade de Software 2008/23 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?

4 Tópicos Especiais - Qualidade de Software 2008/24 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.

5 Tópicos Especiais - Qualidade de Software 2008/25 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.

6 Tópicos Especiais - Qualidade de Software 2008/26 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.

7 Tópicos Especiais - Qualidade de Software 2008/27 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).

8 Tópicos Especiais - Qualidade de Software 2008/28 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?

9 Tópicos Especiais - Qualidade de Software 2008/29 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

10 Tópicos Especiais - Qualidade de Software 2008/210 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

11 Tópicos Especiais - Qualidade de Software 2008/211 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.

12 Tópicos Especiais - Qualidade de Software 2008/212 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.

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

14 Tópicos Especiais - Qualidade de Software 2008/214 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

15 Tópicos Especiais - Qualidade de Software 2008/215 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

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

17 Tópicos Especiais - Qualidade de Software 2008/217 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.

18 Tópicos Especiais - Qualidade de Software 2008/218 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

19 Tópicos Especiais - Qualidade de Software 2008/219 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

20 Tópicos Especiais - Qualidade de Software 2008/220 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.

21 Tópicos Especiais - Qualidade de Software 2008/221 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).

22 Tópicos Especiais - Qualidade de Software 2008/222 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).

23 Tópicos Especiais - Qualidade de Software 2008/223 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).

24 Tópicos Especiais - Qualidade de Software 2008/224 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.

25 Tópicos Especiais - Qualidade de Software 2008/225 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.

26 Tópicos Especiais - Qualidade de Software 2008/226 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

27 Tópicos Especiais - Qualidade de Software 2008/227 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).

28 Tópicos Especiais - Qualidade de Software 2008/228 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).

29 Tópicos Especiais - Qualidade de Software 2008/229 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?

30 Tópicos Especiais - Qualidade de Software 2008/230 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.

31 Tópicos Especiais - Qualidade de Software 2008/231 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.

32 Tópicos Especiais - Qualidade de Software 2008/232 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).

33 Tópicos Especiais - Qualidade de Software 2008/233 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).

34 Tópicos Especiais - Qualidade de Software 2008/234 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).

35 Tópicos Especiais - Qualidade de Software 2008/235 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).

36 Tópicos Especiais - Qualidade de Software 2008/236 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).

37 Tópicos Especiais - Qualidade de Software 2008/237 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).

38 Tópicos Especiais - Qualidade de Software 2008/238 Exemplo: Ferramenta GeRis Teste de Caso de Uso – Perfil de Uso Projeto:Geris Documento Base:Documento de Especificação de Requisitos – Versão 1.1 Caso de UsoFluxo de EventosTipoFreq.Criti. Importância 1Controlar Versão de Plano de RiscosCriar Nova Versão de Plano de RiscosCurso NormalBaixaAltaMédia Criar Nova Versão de Plano de RiscosCurso AlternativoMédiaAlta Criar Nova Versão de Plano de RiscosCurso de ExceçãoBaixa Alterar Versão de Plano de RiscosCurso NormalAlta Consultar Versão de Plano de RiscosCurso NormalMédia Excluir Versão de Plano de RiscosCurso NormalBaixa 2Identicar Riscos Curso NormalMédiaAlta 3Avaliar RiscoEfetuar Avaliação de RiscoCurso NormalMédiaAlta Efetuar Avaliação de Risco: Ação de mitigação aplicada Curso AlternativoBaixa Efetuar Avaliação de Risco: Risco ocorreuCurso AlternativoBaixaMédia Efetuar Avaliação de RiscoCurso de ExceçãoBaixaMédia Excluir Avaliação de RiscoCurso NormalBaixaMédia Excluir Avaliação de RiscoCurso de ExceçãoBaixaMédia 4Definir Riscos Gerenciados Curso NormalMédiaAlta

39 Tópicos Especiais - Qualidade de Software 2008/239 Exemplo: Ferramenta GeRis Teste de Caso de Uso – Perfil de Uso Projeto:Geris Documento Base:Documento de Especificação de Requisitos – Versão 1.1 Caso de UsoFluxo de EventosTipoFreq.Criti. Importância 5Planejar Ações Curso NormalMédiaAlta 6Finalizar Versão de Plano de Riscos Curso NormalMédiaAlta 7Cadastrar ConseqüênciaCriar Nova ConseqüênciaCurso NormalBaixa Criar Nova ConseqüênciaCurso de ExceçãoBaixa Alterar ConseqüênciaCurso NormalBaixa Alterar ConseqüênciaCurso de ExceçãoBaixa Consultar ConseqüênciaCurso NormalBaixa Excluir ConseqüênciaCurso NormalBaixa

40 Tópicos Especiais - Qualidade de Software 2008/240 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).

41 Tópicos Especiais - Qualidade de Software 2008/241 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).

42 Tópicos Especiais - Qualidade de Software 2008/242 Exemplo: Ferramenta GeRis Teste de Caso de Uso Projeto:Geris Documento Base:Documento de Especificação de Requisitos Versão:1.1 Caso de UsoFluxo de EventosEntradasClasse de Equivalência Válida Classe de Equivalência Inválida Saida Esperada 1Controlar Versão de Plano de Riscos Criar Nova Versão de Plano de Riscos (curso normal) nome da versãocadeia de caracteres, exceto apenas espaços nova versão criada cadeia vaziaErro: nome inválido cadeia contendo apenas espaços Erro: nome inválido nome já existenteErro: nome já existente Criar Nova Versão de Plano de Riscos (curso alternativo) versão baseversão base selecionada nova versão criada contendo os dados da versão base

43 Tópicos Especiais - Qualidade de Software 2008/243 Exemplo: Ferramenta GeRis Caso de Teste EntradasClasse de Equivalência Exercitada Critério UtilizadoSaida EsperadaResultado da Execução do Teste 1.1.anome da versão = "Versão 1" cadeia de caracteres, exceto apenas espaços Teste Funcional Sistemático: Valor típico esperado nova versão criada 1.1.bnome da versão = "Versão 1.0" cadeia de caracteres, exceto apenas espaços Teste Funcional Sistemático: Valor típico esperado, 2o elemento nova versão criada 1.1.cnome da versão = > cadeia vaziaTeste Funcional Sistemático: Valor ilegal Erro: nome inválido 1.1.dnome da versão = " "cadeia contendo apenas espaços Teste Funcional Sistemático: Valor ilegal Erro: nome inválido 1.1.enome da versão = 1.0cadeia de caracteres, exceto apenas espaços Teste Funcional Sistemático: Entrada válida, mas que pode ser interpretada como tipo ilegal nova versão criada 1.1.fnome da versão = 1.0nome já existenteTeste Funcional Sistemático: Valor ilegal Erro: nome já existente 1.1.gnome da versão = 1.1versão base selecionada Teste Funcional Sistemático: Valor típico esperado nova versão criada contendo os dados da versão base versão base = hnome da versão = 1.2 Teste Funcional Sistemático: Valor típico esperado, 2o elemento nova versão criada contendo os dados da versão base versão base = 1.1

44 Tópicos Especiais - Qualidade de Software 2008/244 Exemplo: Ferramenta GeRis Teste de Caso de Uso Projeto:Geris Documento Base:Documento de Especificação de Requisitos Versão:1.1 Caso de UsoFluxo de EventosEntradasClasse de Equivalênc ia Válida Classe de Equivalênci a Inválida Saida Esperada 3Avaliar RiscoEfetuar Avaliação de Risco (curso normal) risco a ser avaliado risco selecionado avaliação de risco criada para o risco selecionado probabilidade (p)0 <= p <= 100% impacto (i)0 <= i <= 10 risco a ser avaliado nenhum risco selecionado probabilidade (p) p 100%Erro: probabilidade deve ser um valor entre 0 e 100% impacto (i) i 10Erro: impacto deve ser um valor entre 0 e 10

45 Tópicos Especiais - Qualidade de Software 2008/245 Exemplo: Ferramenta GeRis CasoTesteEntradasClasse de Equivalência Exercitada Critério UtilizadoSaida EsperadaResultado 3.1.arisco a ser avaliado = qualquer risco selecionadoTeste Funcional Sistemático: Valor típico esperado avaliação de risco criada para o risco selecionado probabilidade (p) = 60%0 <= p <= 100% impacto (i) = 50 <= i <= brisco a ser avaliado = qualquer risco selecionadoTeste Funcional Sistemático: Valor típico esperado, 2o elemento avaliação de risco criada para o risco selecionado probabilidade (p) = 80%0 <= p <= 100% impacto (i) = 30 <= i <= crisco a ser avaliado = nenhum nenhum risco selecionadoAnálise de Valor Limite: Condição de entrada especificando uma quantidade de valores: Nenhum valor de entrada 3.1.drisco a ser avaliado = quaisquer dois riscos mais de um risco selecionado Análise de Valor Limite: Condição de entrada especificando uma quantidade de valores: Qte máxima + 1

46 Tópicos Especiais - Qualidade de Software 2008/246 Exemplo: Ferramenta GeRis CasoTesteEntradasClasse de Equivalência Exercitada Critério UtilizadoSaida EsperadaResultado 3.1.eprobabilidade (p) = 0 (demais dados válidos) 0 <= p <= 100%Análise de Valor Limite: Condição de entrada especificando um intervalo de valores: Limite inferior avaliação de risco criada para o risco selecionado 3.1.fprobabilidade (p) = 100% (demais dados válidos) 0 <= p <= 100%Análise de Valor Limite: Condição de entrada especificando um intervalo de valores: Limite superior avaliação de risco criada para o risco selecionado 3.1.gprobabilidade (p) = -0.1% (demais dados válidos) p 100%Análise de Valor Limite: Condição de entrada especificando um intervalo de valores: Valor menor do que o limite inferior Erro: probabilidade deve ser um valor entre 0 e 100% 3.1.hprobabilidade (p) = 100,1% (demais dados válidos) p 100%Análise de Valor Limite: Condição de entrada especificando um intervalo de valores: Valor maior do que o limite superior Erro: probabilidade deve ser um valor entre 0 e 100%

47 Tópicos Especiais - Qualidade de Software 2008/247 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.

48 Tópicos Especiais - Qualidade de Software 2008/248 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.

49 Tópicos Especiais - Qualidade de Software 2008/249 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.

50 Tópicos Especiais - Qualidade de Software 2008/250 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).

51 Tópicos Especiais - Qualidade de Software 2008/251 Teste de Sistema Teste do sistema completo ou de um incremento a ser implantado provendo algum grau de funcionalidades para usuários finais. O foco dos testes de sistema não é exatamente procurar defeitos que conduzam a falhas, mas procurar defeitos que representem variações entre o que o sistema realmente faz e os requisitos especificados para ele. Os tipos de teste nesta fase estão direta ou indiretamente relacionados a requisitos, tanto funcionais quanto não funcionais.

52 Tópicos Especiais - Qualidade de Software 2008/252 Teste de Sistema Os testes de sistema que enfocam requisitos funcionais são análogos aos testes de subsistema. Ou seja, visam testar se os vários casos de uso se comportam adequadamente no contexto, agora, do sistema (ou do incremento a ser implantado). Mas agora é muito importante também que usuários testem efetivamente o sistema, pois pode haver problemas na especificação dos requisitos. Testes dessa natureza são ditos testes de aceitação.

53 Tópicos Especiais - Qualidade de Software 2008/253 Teste de Sistema Para testar requisitos funcionais, testes de ciclo de vida do domínio podem ser aplicados. A idéia de perfil de uso (teste de caso de uso) também pode ser aplicada. Para testar requisitos não funcionais (RNF), é necessário: Definir RNFs como atributos mensuráveis. Projetar casos de teste que detectem a presença ou ausência desses atributos. Executar os casos de teste e analisar os resultados.

54 Tópicos Especiais - Qualidade de Software 2008/254 Teste de Sistema Há diversos tipos de testes de sistemas, focando alguma particularidade ou tipo de RNF, tais como: Teste de Implantação (instalação/remoção do sistema) Teste de Inicialização Teste de Configuração de Hardware e Software Teste de Ambiente (rodar vários programas ao mesmo tempo, simulando situações típicas do usuário) Teste de Exceção e Recuperação Teste de Desempenho Teste de Segurança Teste de Estresse etc

55 Tópicos Especiais - Qualidade de Software 2008/255 Referências Booch, G., Rumbaugh, J., Jacobson, I., UML Guia do Usuário, 2a edição, Editora Campus, Delamaro, M.E., Maldonado, J.C., Jino, M., Introdução ao Teste de Software, Série Campus – SBC, Editora Campus, McGregor, J.D., Sykes, D.A., A Practical Guide to Testing Object-Oriented Software, Addison- Wesley, Pressman, R.S., Engenharia de Software. 6a edição, McGrawHill, 2006.


Carregar ppt "Teste de Software Parte 4 Ricardo de Almeida Falbo Tópicos Especiais – Qualidade de Software 2008/2 Departamento de Informática Universidade Federal do."

Apresentações semelhantes


Anúncios Google