teste de software parte 2 ricardo de almeida falbo tópicos especiais – qualidade de software...

Teste de SoftwareParte 2

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 Processo de Teste Planejamento de Teste Teste Orientado a Objetos


Processo de Teste Independentemente da fase de teste, o processo

de teste inclui as seguintes atividades: Planejamento de Teste Análise de Requisitos de Teste (normalmente realizado

em conjunto com o Planejamento de Teste) Projeto de Casos de Teste Implementação de Casos de Teste Execução Análise


Planejamento de Teste Questões importantes:

Quem deve realizar os testes? O que testar? Que partes devem ser mais

cuidadosamente testadas? (Análise de Requisitos de Teste)

Quanto teste é adequado? Quando testar? Como o teste deve ser realizado?


Quem deve realizar os testes?

Desenvolvedores Testadores Independentes

Compartilhamento de Responsabilidades entreDesenvolvedores eTestadores Independentes


Quem deve realizar os testes? Desenvolvedor:

Código é resultado de seu trabalho. Logo, procurar defeitos é, de certo modo, a destruição do mesmo, e o próprio desenvolvedor não tem motivação psicológica para projetar casos de teste que demonstrem que seu produto tem defeitos (dissonância cognitiva).

Dificilmente o desenvolvedor consegue criar um caso de teste que rompa com a lógica de funcionamento de seu próprio código (Koscianski e Soares, 2006).

Testador Independente: Assume a “perspectiva de teste”. Pode representar papéis distintos (testador de unidade,

de integração e de sistema). Se responsável por todos os testes, em todas as fases,

pode tornar o processo lento e pouco produtivo.


Quem deve realizar os testes? Compartilhamento de Responsabilidades:

Divisão por Fases: Desenvolvedores testam unidades, muitas vezes em

paralelo com a implementação das mesmas. Testadores independentes testam integração e sistema.

Divisão por Atividades do Processo de Teste: Testadores independentes são responsáveis pelo

Planejamento, Análise e Projeto de Casos de Teste Desenvolvedores são responsáveis pela construção e

execução dos casos de teste.


O que testar?

Não testar nada Testar tudoTestar parcialmente


O que testar? Princípio de Pareto adaptado ao teste: 20% dos

componentes de software concentram 80% dos defeitos.

Esse princípio sugere que os esforços devem ser concentrados nas partes mais importantes e/ou frágeis.

Um bom teste é ao mesmo tempo econômico e encontra o máximo de defeitos (Koscianski e Soares, 2006).

Análise de Requisitos de Teste: Quais as partes mais importantes? Quais as mais frágeis? Enfim, que partes devem ser mais cuidadosamente testadas?


O que testar? Exemplo - Teste de Unidade: testar todas as

unidades? Testar unidades reutilizadas de outros projetos?

Utilizar uma abordagem sistemática para selecionar o subconjunto de componentes a ser testado.

Algumas diretrizes (McGregor e Sykes, 2001): Pode não ser necessário testar unidades reutilizadas de

outros projetos ou de bibliotecas. Algumas unidades não são fáceis de serem testadas

individualmente, requerendo drivers e/ou stubs complexos.

Concentrar esforços em usos prováveis.


Quanto teste é adequado?

Nenhum teste Teste Exaustivo


Quanto teste é adequado? É impossível testar tudo. Testes podem somente mostrar a presença de

erros, mas não a sua ausência. Cobertura de Teste pode ser medida pelo menos

de duas maneiras (McGregor e Sykes, 2001): Em relação a requisitos: quanto dos requisitos

especificados foi testado? Considerar requisitos funcionais (casos de uso, fluxos de eventos) e não funcionais.

Em relação à execução de linhas de código (teste de caminhos possíveis).


Quanto teste é adequado? O esforço de teste deve ser compensatório, ou

seja, deve haver um balanceamento entre tempo/custo do teste e a quantidade de defeitos encontrados.

O número de defeitos encontrados segue uma curva logarítmica, ou seja, embora ainda possam existir defeitos, o esforço para encontrá-los passa a ser muito grande, fazendo com que a atividade de teste comece a ser percebida como muito custosa (Koscianski e Soares, 2006).


Quando testar?

Todo dia Testar nofinal

Na medida em que oscomponentes são desenvolvidos


Quando testar? Teste como uma atividade do processo de

software (testar no final) x Teste como um processo paralelo ao processo de desenvolvimento (teste todo dia)

Revisões e testes são atividades complementares.

Planejar, analisar e projetar testes à medida que o processo de desenvolvimento progride.

Utilizar informações do ciclo de vida (incrementos) e dos requisitos (casos de uso) para definir o cronograma de testes.


Quando testar? Cronograma de teste

Teste de Unidade: depende da produção das unidades pelo processo de desenvolvimento.

Teste de Integração: depende do ciclo de vida (incrementos / iterações) e da estrutura (subsistemas / casos de uso). Pode ser programado em intervalos específicos.

Teste de Sistema: sua execução deve ocorrer nas entregas e, portanto, depende do ciclo de vida.


Como testar?

Apenas com o conhecimentoda especificação(o quê)

Usando o conhecimentoda especificação e da implementação(o quê e como)

Apenas com o conhecimentoda implementação(como)


Como testar? Definir técnicas de teste para cada fase

(funcional, estrutural, baseado em modelos, baseado em defeitos).


Estimativas e Riscos Como qualquer atividade de planejamento,

planejar testes envolve a gerência de riscos e a realização de estimativas de esforço, recursos (pessoas, equipamentos, software), tempo e custo.

Fatores que afetam as estimativas / riscos: Software sendo testado: tipo de software, plataforma

de implementação etc. Equipamentos e software requeridos para o teste Modelo organizacional (testadores x desenvolvedores) Nível de Cobertura.

Usar dados históricos.


Plano de Testes Como qualquer atividade de planejamento, um

plano de testes deve ser elaborado, descrevendo o escopo, o processo de teste definido, os recursos alocados, estimativas, cronograma e riscos.

Característica específica: deve ser organizado em função dos itens e funcionalidades a serem testados.

Exemplo de Modelo de Plano de Teste: Padrão IEEE 829-1998.


Padrão IEEE 829-1998 Identificador único para o plano de testes. Introdução Itens: identifica os itens a serem testado,

incluindo versão Funcionalidades: identifica as funcionalidades

que serão testadas ou não, bem como os motivos

Processo: especifica as principais atividades, técnicas e ferramentas

Critérios de aceite: especifica os critérios de aceite para cada item


Padrão IEEE 829-1998 Suspensão: especifica os critérios para

suspender parte ou todo o processo de teste Produtos: identifica os artefatos produzidos pelo

processo de teste (planos, casos de teste, relatórios etc)

Tarefas: detalhamento e dependência entre as atividades

Ambiente: identifica as necessidades do ambiente de teste (hardware e software)

Responsabilidades: identifica os responsáveis pelas atividades, pelo ambiente de teste e pelos itens de teste


Padrão IEEE 829-1998 Treinamento: especifica as necessidades de

treinamento e identifica opções Cronograma Riscos: plano de riscos Aprovações: especifica os nomes e cargos dos

responsáveis por aprovar o plano. Devem ser inclusos espaços para assinaturas e datas.


Teste Orientado a Objetos Embora o paradigma OO possa reduzir a

ocorrência de alguns tipos de defeitos cometidos no paradigma procedimental, ele aumenta a chance de ocorrência de outros.

De fato, as características da orientação a objetos, dentre elas Encapsulamento, Herança, Classes Abstratas e Genéricas, Polimorfismo, Containeres Heterogêneos e Conversão de Tipos, introduzem novas fontes de defeitos (Delamaro et al., 2007).


Encapsulamento Refere-se ao mecanismo de controle de acesso a

atributos e métodos de uma classe. Não contribui diretamente para a ocorrência de

defeitos (muito pelo contrário), mas dificulta a obtenção e atualização do estado de um objeto, podendo dificultar os testes (Delamaro et al., 2007).


Herança Classes podem ser definidas em função de

classes já existentes, criando-se uma hierarquia de classes.

Enfraquece o encapsulamento. É possível que subclasses violem condições

requeridas para o correto funcionamento de classes ancestrais.

Grandes hierarquias podem dificultar a compreensão e reduzir a testabilidade de classes.

Herança múltipla: problemas de métodos sobrecarregados e herança repetida (Delamaro et al., 2007).


Classes Abstratas e Genéricas Classe Abstrata: fornece um conjunto incompleto

de funcionalidades, sendo que pelo menos uma delas não possui implementação.

O teste de uma classe abstrata só pode ser realizado após esta ter sido especializada e uma classe concreta ter sido obtida.

Classe Genérica: permite que sejam declarados atributos e parâmetros que podem ser instanciados com objetos de tipos específicos.

Classes genéricas precisam ter o parâmetro genérico substituído por um parâmetro de um tipo específico para serem testadas (Delamaro et al., 2007).


Polimorfismo É caracterizado pela possibilidade de um único nome, dito

nome polimórfico (uma variável ou uma referência), denotar objetos de diferentes classes, que devem possuir uma superclasse comum.

Cada possibilidade de acoplamento de uma mensagem polimórfica é uma computação única.

Um bom conjunto de teste deveria garantir que todos os possíveis acoplamentos polimórficos sejam exercitados ao menos uma vez.

Uma vez que a hierarquia de classes é livremente extensível, é impossível desenvolver um conjunto de teste que garanta a execução do acoplamento em relação a todas as possíveis classes (Delamaro et al., 2007).


Containeres Heterogêneos e Conversão de Tipos

Containeres heterogêneos são estruturas de dados que armazenam objetos que podem pertencer a várias classes diferentes.

Contudo, alguns dos objetos armazenados podem não ter o mesmo conjunto de operações daquelas pertencentes à superclasse raiz de uma hierarquia.

Para permitir que tais objetos façam uso de todos os seus métodos, é possível fazer a conversão (casting) do objeto para qualquer classes na hierarquia (Delamaro et al., 2007).


Containeres Heterogêneos e Conversão de Tipos

Um objeto pode ser convertido para uma classe à qual não pertence, sendo incapaz, portanto, de invocar um determinado método.

Um objeto não convertido para o tipo de sua classe pode estar sendo usado para invocar um método da mesma (Delamaro et al., 2007).


Fases de Teste Teste de Unidade Teste de Integração Teste de Sistema

Software OO é composto de classes que encapsulam uma série de métodos que cooperam entre si na implementação de uma funcionalidade.

O que muda em relação às fases de teste?


Tipos de Teste OO Teste intramétodo:

Testa um método individualmente. A classe à qual pertence o método é o driver.

Teste intermétodo: Testa os métodos de uma classe com a finalidade de

descobrir defeitos de integração entre métodos dentro do escopo da classe em teste.

Testa métodos públicos em conjunto com outros métodos dentro da mesma classe, com o intuito de descobrir defeitos nas interfaces de comunicação entre os métodos (Delamaro et al., 2007).


Tipos de Teste OO Teste intraclasse:

Testa interações entre métodos públicos de uma classe, fazendo-se chamadas a esses métodos em diferentes seqüências.

O objetivo é identificar seqüências de ativação de métodos inválidas que levem o objeto a um estado inconsistente.

Teste interclasse: idem anterior, mas os métodos públicos não

necessitam estar na mesma classe (Delamaro et al., 2007).


Visões das Fases de Teste na Orientação a Objetos

Método como a menor unidade a ser testada. Teste de Unidade: Teste intramétodo. Teste de Integração: Teste intermétodo, Teste

intraclasse e Teste interclasse. Teste de Sistema: toda a aplicação (Delamaro et

al., 2007).



Teste de Unidade: Método

Teste de Integração: Classe Componente Caso de Uso Subsistema

Teste de Sistema Toda aplicação



Classe como a menor unidade a ser testada. Teste de Unidade: Teste intramétodo, Teste

intermétodo e Teste intraclasse. Teste de Integração: Teste interclasse. Teste de Sistema: toda a aplicação (Delamaro et

al., 2007).



Teste de Unidade: Classe

Teste de Integração: Componente Caso de Uso Subsistema

Teste de Sistema Toda aplicação


Fases de Teste OO Teste de Unidade: testa os métodos

individualmente (teste intramétodo). Teste de Classe: testa a interação entre métodos

de uma classe (testes intermétodo e intraclasse). Teste de Integração: testa a interação entre

classes do sistema (teste interclasse). Teste de Sistema: testa a funcionalidade do

sistema como um todo.


Referências Delamaro, M.E., Maldonado, J.C., Jino, M.,

Introdução ao Teste de Software, Série Campus – SBC, Editora Campus, 2007.

Koscianski, A., Soares, M.S., Qualidade de Software, Editora Novatec, 2006.

McGregor, J.D., Sykes, D.A., A Practical Guide to Testing Object-Oriented Software, Addison-Wesley, 2001.

teste de software parte 2 ricardo de almeida falbo tópicos especiais – qualidade de software...

Documents