Cap9 VVT

TESTES DE SOFTWARE
Fonte:
Profa. Maria Auxiliadora PRESSMAN, ROGER - Engenharia de Software - 6° Edição
SOMMERVILLE - Engenharia de Software - 8° Edição 1
Teste de software
• É uma atividade crítica na garantia de
qualidade de software;
• Quatro dimensões:
– Estado do teste (“o momento”);
– Técnica do teste (“como vou testar”);
– Metas do testes (“o que tenho que testar”);
– Onde será o teste (“ambiente do teste”).
Fonte:
2
Objetivos da Atividade de Teste
• Projetar testes que descubram
sistematicamente diferentes classes
de erros e façam-o com uma
quantidade de tempo e esforço
mínimos.
• Se a atividade de teste for conduzida
com sucesso, ela descobrirá erros no
software. Fonte:
PRESSMAN, ROGER - Engenharia de Software - 6° Edição
Profa. Maria Auxiliadora
• A atividade de teste não pode mostrar
a ausência de bugs; ela só pode
mostrar se defeitos de software estão
presentes.
• Se erros graves forem encontrados
com regularidade a qualidade e a
confiabilidade de software são
suspeitas. Fonte:
• Se erros facilmente corrigíveis forem
encontrados  a qualidade e a confiabilidade do
software estão aceitáveis ou os testes são
inadequados para revelar erros graves.
• Se não for encontrado erro  a

configuração de teste não foi suficientemente
elaborada e erros estão escondidos no
software.
Fonte:
Organização para Realização
de Teste de Software
Quando o teste se inicia há um conflito de
interesses:
 Desenvolvedores: interesse em
demonstrar que o programa é isento de
erros.
 Responsáveis pelos testes: interesse

em mostrar que o programa tem erros.
Fonte:
Organização para Realização
de Teste de Software
Do ponto de vista psicológico:
• Análise, Projeto e Codificação de

Software são tarefas construtivas
• Teste é tarefa destrutiva
Fonte:
Verificação e Validação
• Objetivo: assegurar que o software

–Cumpra as suas especificações e atenda às
necessidades dos usuários e clientes.
• Ocorrem em todo o ciclo de vida do software
–Revisões de requisitos, revisões de design,
inspeções de código e teste do produto.
Fonte:
• Validação: “Estamos construindo o produto
certo?”
– O software deve atender às necessidades
dos usuários.
• Verificação: “Estamos construindo o produto
corretamente?”
– O software deve estar de acordo com a sua
especificação.
Fonte:
Metas do processo de
• Função de software
– O nível de confiança depende de
quanto o software é para uma
organização.
• Expectativas de usuário
– Usuários podem ter poucas
expectativas em relação ao software.
Fonte:
Metas do processo de
• Ambiente de mercado
– verificar o momento exato de
colocar o produto no mercado
( com ou sem depuração e teste
do produto).
Fonte:
Planejamento de
• Um planejamento cuidadoso é
necessário para obter o melhor das
inspeções e dos testes e para controlar
os custos do processo de verificação e
validação.
• O planejando de V&V deve se iniciar
no começo do processo de
desenvolvimento. Fonte:
Planejamento de
Especificação Especificação
Projeto de Projeto
de requisitos de sistema
sistema detalhado
Plano de teste Plano de teste Plano de teste

de aceitação de integração de integração Teste de
de sistema de subsistema unicidade e
de módulo
Operação Teste de Teste de

Teste de
aceitação integração
integração
do sistema
do subsistema
Fonte:
O que deve ser
verificado e validado?
• Fatores de Qualidade de Revisão
–Relacionados com a manutenção,
evolução e avaliação do software.
• Fatores de Qualidade de Transição

–Relacionados com a instalação,
reutilização e interação com outros
produtos.
Fonte:
Técnicas de V & V
• Inspeções de software
–(V & V estática)
• Testes de software
–(V & V dinâmica)
Fonte:
Inspeções de Software
• Interessadas na análise da
representação estática do sistema para
descobrir problemas
Pode ser suplementado por
ferramentas baseadas em documentos
e análise de códigos.
Fonte:
Teste de Inspeção
Fonte:
Inspeções de Programas
• Revisões cujo objetivo é a detecção

de defeitos no programa.
• Principal meta  DESCOBERTA de
•
defeito (não correção).
• Defeitos podem ser erros lógicos,
anomalias no código que poderia
indicar uma condição errônea.
Fonte:
Checagem de Inspeções
• Defeitos nos dados:
–Todas as variáveis de programa são
iniciadas antes de seus valores serem
utilizados?
–Todas as constantes foram
denominadas?
–Existe alguma possibilidade de
overflow de buffer (limite de
vetores)?
SOMMERVILLE
Fonte:
- Engenharia de Software - 8° Edição 19
• Defeitos de controle:
– Para cada condição condicional

a condição está correta?
– As declarações compostas estão
corretamente entre parênteses?
Fonte:
• Defeitos de entrada e saída
–Todas as variáveis de entrada

são utilizadas?
–Todas as variáveis de saída têm
um valor designado antes de
saírem?
Fonte:
• Defeitos de interface
–Todas as chamadas de funções

e métodos têm o número
correto de parâmetros?
–Os parâmetros estão em ordem
corretas?
Fonte:
• Defeito de gerenciamento de
armazenamento
–Se o armazenamento dinâmico é
utilizado, o espaço foi alocado
corretamente?
–O espaço é explicitamente
liberado, depois que não é mais
necessário?
Fonte:
Teste de software
(dinâmica)
Fonte:
24
Teste de Validação - escopo
• Objetivo: Avaliar a possibilidade de uso do
sistema
• Quem faz: Cliente ou usuário final
• O que é testado: Funções principais,
documentação e procedimentos
• Quando termina: Em geral, quando o
usuário se sente a vontade, ou quando o
teste proposto dá bom resultado.
Fonte:
Teste de Programa
• Um teste próspero é um teste que
descobre um ou mais erros.
• Elaboração de casos de testes

baseados na especificação funcional
–Dados de entradas.
–Comportamento esperado.
Fonte:
Teste de Programa
• Podem ser classificados
–Quanto ao método: defeitos e

estatísticos.
–Quanto ao escopo: unicidade,

integração, sistema e aceitação.
Fonte:
Tipos de Testes – (Método)
• Testes de defeitos
– Tem por objetivo encontrar defeitos –
inconsistências entre o programa e a
sua especificação.
– Verifica a correção – conhecido também
por testes de correção.
– Normalmente realizados com
protótipos funcionais.
Fonte:
Tipos de Testes – (Método)
• Testes estatísticos
– Utilizados para avaliar o
desempenho e a confiabilidade –
checar como ele trabalha nas
condições operacionais
• Exemplos de medições:
–Número de falhas observadas
–Tempos de resposta
–Tempos de execução
Fonte:
Teste de Programa
Fase de Categorias de Testes Características da Fase de
Validação Aplicadas Validação
 Estrutura Interna  Estratégia caixa branca e

 Funcionalidade caixa preta.
 Usabilidade  Testar partes do software.
Teste de  Segurança  Requer conhecimento da
Unidade estrutura interna.
 Executada pelo
desenvolvedor ou
profissional de teste.
Teste de  Interfaces  Estratégia de caixa branca e
Baixo Nível  Dependência caixa preta.
entre  Testa integrações entre
Componentes partes de software.
Teste de  Requer conhecimento da
Integração arquitetura interna do
software.
 Executada pelo
Fonte: desenvolvedor ou
SOMMERVILLE profissional de teste.
- Engenharia de Software - 8° Edição 30
Teste de Programa
Fase de Categorias de Testes Características da Fase de
Validação Aplicadas Validação
 Funcionais  Estratégia de caixa preta.
 Não Funcionais  Os testes são aplicados no
o Performance software como todo.
o Instalação  Não requer conhecimento da
o Recuperação estrutura interna do
Teste de Teste de
o Carga software.
Alto Nível sistema
 Requer ambiente muito
semelhante ao da produção.
 Deves ser executada por um
grupo de teste
independente.
Fonte:
Tipos de Unicidade
Esquema
Fonte:
Tipos de Unicidade
• É o processo de teste de componentes
individuais isoladamente.
• As unidades podem ser:
Funções individuais ou métodos dentro de um objeto

Classes de objetos com vários atributos e métodos
Componentes compostos com interfaces definidas
usados para acessar suas funções.
Fonte:
Tipos de Unicidade
Fonte:
Testes de Integração
• Concentra-se no projeto e na
construção da arquitetura de software.
• Conhecidos como testes em ponto
grande.
• Os componentes são integrados e o
conjunto maior é testado – módulo e
subsistemas.
Fonte:
• Tipos de interfaces
 Interfaces de parâmetro - Dados passados de um método ou

procedimento para o outro.
 Interfaces de memória compartilhada - Blocos de memória são
compartilhados entre os procedimentos ou funções.
 Interfaces de procedimento - Subsistemas sintetizam um conjunto
de procedimentos para serem chamados por outros subsistemas.
 Interfaces de passagem de mensagem - Subsistemas solicitam
serviços de outros subsistemas.
Fonte:
• Quem faz: Geralmente o programador.
• O que é testado: A integração entre os
módulos.
• Quando termina: Quando o
programador verifica que a
interligação entre os módulos se
encontra bem definida.
Fonte:
• Não-Incremental: As unidades são
combinadas e o programa completo é
testado como um todo.
• Incremental: Combina o módulo
seguinte a ser testado com o conjunto de
módulos já testados, existem alguns
tipos:
– Integração Top-down.
– Integração Bottom-up. Fonte:
Integração Top-down
• Módulos são integrados de cima para

baixo, partindo-se do módulo principal.
• Pode ser realizada, de duas maneiras:

−por profundidade (depth first)
−por largura (breadth first)
Fonte:
Integração Top-down
Fonte:
Integração Bottom-up
• Início da construção e dos testes com
módulos atômicos (localizados no nível
mais baixo da estrutura do sistema).
• Quando os módulos de níveis superiores

vão ser testados, os módulos
subordinados já estão prontos e portanto,
não se torna necessária a criação de
stubs.
Fonte:
Integração Bottom-up
Mc
Ma Mb
D1 D2 D3
Cluster 3
Cluster 1
Cluster 2
Fonte:
Vantagens e desvantagens
• Integração Top-down:
– Vantagem: Testar logo no início as funções principais
do software.
– Desvantagem: necessidade de simuladores.
• Integração Bottom-up:
– Vantagem: permite que as unidades mais básicas
sejam testadas mais cedo.
– Desvantagem: O módulo principal não existe até que
todos os módulos estiverem testados.
Fonte:
Teste de Sistema
• Verificar se as funções estão de acordo com a
especificação e se todos os elementos do
sistema combinam-se adequadamente.
• Quem faz: Líder do projeto ou grupo de

teste;
• O que é testado: Necessidades técnicas e
funcionais do sistema. Interfaces do sistema;
Fonte:
Teste de Sistema
• Quando termina: Em geral, quando a

maioria das necessidades é atendida,
permanecendo poucos erros
importantes;
• Recursos extras: Biblioteca de casos
de testes. Geradores, comparadores e
simuladores de teste em massa.
Fonte:
Teste de Sistema
• Envolve uma série de diferentes testes,
cujo propósito primordial é pôr
completamente à prova o sistema
baseado em computador.
• Se divide em quatro testes:
– Teste de Recuperação;
– Teste de Estresse;
– Teste de Desempenho;
– Teste de Segurança.
Fonte:
Teste de Sistema
• Teste de Recuperação
−É um teste de sistema que força o
software a falhar de diversas
maneiras e verifica se a
recuperação é adequadamente
executada.
Fonte:
Teste de Sistema
• Teste de Estresse
–Confronta os programas com
situações anormais de frequência,
volume ou recursos em
quantidade.
–Pode ser utilizada uma lista com
situações padrão de provocação
de “estresse do sistema”.
Fonte:
Teste de Sistema
• Teste de Desempenho
−Testa o tempo de resposta do
sistema e é aplicado geralmente
para sistemas de tempo real.
−Preocupa-se com o rendimento,
tempo de resposta e capacidade
( especialmente a capacidade do
banco de dados.)
Fonte:
Teste de Sistema
• Teste de Segurança
– Tenta verificar se todos os mecanismos de
proteção embutidos num sistema o
protegerão, de fato, de acessos indevidos.
– A estratégia de teste deve ser feita por
programadores que não desenvolveram o
software.
– Os testadores devem tentar invadir o sistema
de várias formas: obtenção ilegal de senhas,
desarme do sistema e outros.
Fonte:
Teste de Aceitação
• Objetivo: Avaliar a possibilidade de uso do
sistema;
• Quem faz: Cliente ou usuário final;
• O que é testado: Funções principais,

documentação e procedimentos;
• Quando termina: Em geral, quando o usuário

se sente a vontade, ou quando o teste proposto
dá bom resultado.
Fonte:
Revisão da configuração
Fonte:
• Tipos:
– Alfa: É feito por um cliente nas
instalações do desenvolvedor. O
software é usado num ambiente
controlado com o desenvolvedor
"olhando sobre os ombros“ do usuário e
registrando erros e problemas de uso.
Fonte:
• Tipos....
− Beta: É realizado nas instalações do
cliente pelo usuário final do
software. O desenvolvedor não está
presente, e o cliente registra os
problemas que são encontrados e
relata-os ao desenvolvedor
posteriormente.
Fonte:
Projeto de Casos de Teste
– Oferece uma abordagem
sistemática ao teste;
− É um mecanismo que ajuda a

garantir a mais alta probabilidade
de revelar erros no software com
uma quantidade mínima de tempo
e esforço. Fonte:
Projeto de Casos de Teste
• Teste de Caixa Preta (teste funcional)
• Teste de Caixa Branca (teste estrutural)
 Teste de Caminho Básico
–Caminho Independente
–Complexidade Ciclomática
 Teste de Estrutura de Controle
−Teste de Condição
−Teste de Fluxo de Dados
−Teste de Laços
 Teste no contexto de OO
Fonte:
Teste Funcional (caixa preta)
• O programa é uma caixa preta cujo
comportamento é determinado
estudando-se as suas entradas e saídas.
• Os casos de testes são derivados da
especificação funcional.
• A escolha dos dados de entrada podem
ser feitas com várias técnicas:
– Partição de domínio
– Análise de valor limite
Fonte:
• Envolve dois passos principais:

–Identificar as funções que o
software deve realizar
(especificação dos requisitos)
–Criar casos de teste capazes de
checar se essas funções estão
sendo executadas corretamente.
Fonte:
Entradas
Entrada de dados I que provocam
de teste e comportamento anômalo
Sistema
Saídas que revelam a

Saída dos resultados Oe presença de defeitos
de teste
Fonte:
• Problemas:
−Dificuldade em quantificar a
atividade de teste: não se pode
garantir que partes essenciais ou
críticas do software foram
executadas.
−Dificuldade de automatização.
Fonte:
Teste estrutural (caixa branca)
• São testados os caminhos lógicos

através do software, fornecendo
casos de teste que põem à prova
conjuntos específicos de condições
e/ou laços.
• Exercita as estruturas de dados
internas para garantir a sua validade;
Fonte:
• Executa todos os laços em suas

fronteiras;
• Exercita todas as decisões
lógicas para valores falsos ou
verdadeiros.
Fonte:
Dados de teste
testa Deriva
Saídas do
Código de
teste
componente
Fonte:
Teste de Caminho Básico
O teste de caminho básico
possibilita que o projetista do caso
de teste derive uma medida de
complexidade lógica de um projeto
procedimental e use essa medida
como guia para definir um conjunto
básico de caminhos de execução.
Fonte:
Teste de Caminho Básico
Fonte:
Fluxograma e Grafo de Fluxo
1
1
2
2
3
3 6 4, 5
8
7
6 4
9
7 8 5 10
9
10 11
11
Fluxograma Grafo de fluxo

Fonte:
Teste de software
Configuração
Esquema
de Software
Depuração
Resultados Erros
Atividades
de Teste dos Testes
Correções
Avaliação
Dados da Confiabilidade
Configuração Resultados Taxa de Prevista
de Teste Esperados Erros
Modelo de
Confiabilidade
Fonte:
Ferramentas de Automatização
• Uma ferramenta de teste reduz
a intervenção humana nos
resultados obtidos, aumentando
a qualidade e a produtividade
da atividade de teste. Influencia
diretamente a confiabilidade do
software testado.
Fonte:
Tipos de Ferramentas
• Estáticas: verificam portabilidade, estilo e são
independentes da qualidade dos casos de
teste.
• Dinâmico – Monitoram a execução do
programa. Adiciona código a um programa
para contar o número de vezes que cada
declaração foi executada.
• Simulador – simulam a máquina em que o
programa deve ser executado.
Fonte:

Cap9 VVT

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Cap9 VVT

Enviado por

Direitos autorais:

Formatos disponíveis

TESTES DE SOFTWARE

• Se não for encontrado erro  a

 Responsáveis pelos testes: interesse

• Análise, Projeto e Codificação de

• Teste é tarefa destrutiva

• Objetivo: assegurar que o software

Plano de teste Plano de teste Plano de teste

Operação Teste de Teste de

• Fatores de Qualidade de Transição

• Revisões cujo objetivo é a detecção

– Para cada condição condicional

–Todas as variáveis de entrada

–Todas as chamadas de funções

• Elaboração de casos de testes

–Quanto ao método: defeitos e

–Quanto ao escopo: unicidade,

 Estrutura Interna  Estratégia caixa branca e

• As unidades podem ser:

Funções individuais ou métodos dentro de um objeto

 Interfaces de parâmetro - Dados passados de um método ou

• Módulos são integrados de cima para

• Pode ser realizada, de duas maneiras:

• Quando os módulos de níveis superiores

• Quem faz: Líder do projeto ou grupo de

• Quando termina: Em geral, quando a

• Quem faz: Cliente ou usuário final;

• O que é testado: Funções principais,

• Quando termina: Em geral, quando o usuário

− É um mecanismo que ajuda a

• Envolve dois passos principais:

Saídas que revelam a

• São testados os caminhos lógicos

• Executa todos os laços em suas

Fluxograma Grafo de fluxo

Você também pode gostar