Aula 9 - Teste de Software - Parte 4

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


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?


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.


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.


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.


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).


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?


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


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


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.


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.


Partição Baseada em Estado Seja a seguinte classe Conta.

Que operações mudam o estado? Que casos de teste considerar?


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


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


Partição Baseada em Atributo Seja a seguinte classe Conta.

Que operações usam / modificam / não usam cada um dos atributos?


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.


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


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


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.


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).


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).


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).


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.


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.


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


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).


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).


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?


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.


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.


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).


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).


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).


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).


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).


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).


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


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


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).


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).


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


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


1.1.d nome da versão = " " cadeia contendo apenas espaços

Teste Funcional Sistemático: Valor ilegal


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


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


versão base = 1.1 versão base = 1.1



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


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


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



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


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


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%


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.



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.



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.


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).


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.


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.


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.


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


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.

Aula 9 - Teste de Software - Parte 4

Documents

Transcript of Aula 9 - Teste de Software - Parte 4