Upload
internet
View
109
Download
0
Embed Size (px)
Citation preview
Teste de SoftwareParte 4
Ricardo de Almeida Falbo
Tópicos Especiais – Qualidade de Software 2008/2
Departamento de InformáticaUniversidade Federal do Espírito Santo
Tópicos Especiais - Qualidade de Software 2008/2 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 Teste de Caso de Uso – Perfil de Uso
Projeto: Geris
Documento Base: Documento de Especificação de Requisitos – Versão 1.1
Caso de Uso Fluxo de Eventos Tipo Freq. Criti. Importância
1 Controlar Versão de Plano de Riscos Criar Nova Versão de Plano de Riscos Curso Normal Baixa Alta Média
Criar Nova Versão de Plano de Riscos Curso Alternativo Média Alta Alta
Criar Nova Versão de Plano de Riscos Curso de Exceção Baixa Baixa Baixa
Alterar Versão de Plano de Riscos Curso Normal Alta Alta Alta
Consultar Versão de Plano de Riscos Curso Normal Média Média Média
Excluir Versão de Plano de Riscos Curso Normal Baixa Baixa Baixa
2 Identicar Riscos Curso Normal Média Alta Alta
3 Avaliar Risco Efetuar Avaliação de Risco Curso Normal Média Alta Alta
Efetuar Avaliação de Risco: Ação de mitigação aplicada
Curso Alternativo Baixa Baixa Baixa
Efetuar Avaliação de Risco: Risco ocorreu Curso Alternativo Baixa Média Média
Efetuar Avaliação de Risco Curso de Exceção Baixa Média Média
Excluir Avaliação de Risco Curso Normal Baixa Média Média
Excluir Avaliação de Risco Curso de Exceção Baixa Média Média
4 Definir Riscos Gerenciados Curso Normal Média Alta Alta
Tópicos Especiais - Qualidade de Software 2008/2 39
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 Uso Fluxo de Eventos Tipo Freq. Criti. Importância
5 Planejar Ações Curso Normal Média Alta Alta
6 Finalizar Versão de Plano de Riscos Curso Normal Média Alta Alta
7 Cadastrar Conseqüência Criar Nova Conseqüência Curso Normal Baixa Baixa Baixa
Criar Nova Conseqüência Curso de Exceção Baixa Baixa Baixa
Alterar Conseqüência Curso Normal Baixa Baixa Baixa
Alterar Conseqüência Curso de Exceção Baixa Baixa Baixa
Consultar Conseqüência Curso Normal Baixa Baixa Baixa
Excluir Conseqüência Curso Normal Baixa Baixa Baixa
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 Teste de Caso de Uso
Projeto: Geris
Documento Base: Documento de Especificação de Requisitos
Versão: 1.1
Caso de Uso Fluxo de Eventos Entradas Classe de Equivalência Válida
Classe de Equivalência Inválida
Saida Esperada
1 Controlar Versão de Plano de Riscos
Criar Nova Versão de Plano de Riscos (curso normal)
nome da versão cadeia de caracteres, exceto apenas espaços
nova versão criada
cadeia vazia Erro: nome inválido
cadeia contendo apenas espaços
Erro: nome inválido
nome já existente Erro: nome já existente
Criar Nova Versão de Plano de Riscos (curso alternativo)
versão base versão base selecionada
nova versão criada contendo os dados da versão base
Tópicos Especiais - Qualidade de Software 2008/2 43
Exemplo: Ferramenta GeRisCaso de Teste
Entradas Classe de Equivalência Exercitada
Critério Utilizado Saida Esperada Resultado da Execução do Teste
1.1.a nome 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.b nome 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.c nome da versão = <<cadeia vazia>>
cadeia vazia Teste Funcional Sistemático: Valor ilegal
Erro: nome inválido
1.1.d nome da versão = " " cadeia contendo apenas espaços
Teste Funcional Sistemático: Valor ilegal
Erro: nome inválido
1.1.e nome da versão = 1.0 cadeia 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.f nome da versão = 1.0 nome já existente Teste Funcional Sistemático: Valor ilegal
Erro: nome já existente
1.1.g nome da versão = 1.1 versã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 = 1.0
1.1.h nome da versão = 1.2 nome 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 versão base = 1.1
Tópicos Especiais - Qualidade de Software 2008/2 44
Exemplo: Ferramenta GeRis
Teste de Caso de Uso
Projeto: Geris
Documento Base: Documento de Especificação de Requisitos
Versão: 1.1
Caso de Uso Fluxo de Eventos Entradas Classe de Equivalência Válida
Classe de Equivalência Inválida
Saida Esperada
3 Avaliar Risco Efetuar Avaliação de Risco (curso normal)
risco a ser avaliado
risco selecionado avaliação de risco criada para o risco selecionadoprobabilidade (p) 0 <= p <= 100%
impacto (i) 0 <= i <= 10
risco a ser avaliado
nenhum risco selecionado
probabilidade (p) p< 0 ou p > 100% Erro: probabilidade deve ser um valor entre 0 e 100%
impacto (i) i < 0 ou i > 10 Erro: impacto deve ser um valor entre 0 e 10
Tópicos Especiais - Qualidade de Software 2008/2 45
Exemplo: Ferramenta GeRisCasoTeste Entradas Classe de Equivalência
ExercitadaCritério Utilizado Saida Esperada Resultado
3.1.a risco a ser avaliado = qualquer
risco selecionado Teste Funcional Sistemático: Valor típico esperado
avaliação de risco criada para o risco selecionado
probabilidade (p) = 60% 0 <= p <= 100%
impacto (i) = 5 0 <= i <= 10
3.1.b risco a ser avaliado = qualquer
risco selecionado Teste 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) = 3 0 <= i <= 10
3.1.c risco a ser avaliado = nenhum
nenhum risco selecionado Análise de Valor Limite: Condição de entrada especificando uma quantidade de valores: Nenhum valor de entrada
3.1.d risco 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
Tópicos Especiais - Qualidade de Software 2008/2 46
Exemplo: Ferramenta GeRis
CasoTeste Entradas Classe de Equivalência Exercitada
Critério Utilizado Saida Esperada Resultado
3.1.e probabilidade (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.f probabilidade (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.g probabilidade (p) = -0.1% (demais dados válidos)
p< 0 ou 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.h probabilidade (p) = 100,1% (demais dados válidos)
p< 0 ou 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%
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 51
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.
Tópicos Especiais - Qualidade de Software 2008/2 52
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.
Tópicos Especiais - Qualidade de Software 2008/2 53
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.
Tópicos Especiais - Qualidade de Software 2008/2 54
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
Tópicos Especiais - Qualidade de Software 2008/2 55
Referências Booch, G., Rumbaugh, J., Jacobson, I., UML Guia
do Usuário, 2a edição, Editora Campus, 2006. Delamaro, M.E., Maldonado, J.C., Jino, M.,
Introdução ao Teste de Software, Série Campus – SBC, Editora Campus, 2007.
McGregor, J.D., Sykes, D.A., A Practical Guide to Testing Object-Oriented Software, Addison-Wesley, 2001.
Pressman, R.S., Engenharia de Software. 6a edição, McGrawHill, 2006.