teste de software

Prévia do material em texto

Fundamentos de Engenharia de 
Software 
Estratégias de Teste de Software
2
Visão Geral
A Atividade de Teste é um ELEMENTO 
CRÍTICO para a garantia de qualidade 
do software
Representa a última revisão de especificação, 
projeto e codificação
Técnicas que auxiliam no condução dessa 
atividade têm sido propostas...
Introdução
 O que é Qualidade de Software
 Software deve estar em conformidade com:
 requisitos funcionais e de desempenho explicitamente declarados
 normas de desenvolvimento documentados explicitamente documentadas
 e características implícitas, que são esperadas em todo software desenvolvido 
profissionalmente
[Pressman -6ed]
Introdução ao Teste de Software 3
Introdução
 Por quê falham?
 Alterações:
 alterações degradam a estrutura do software, tornando-o cada vez mais 
difícil de alterar
 Tempo:
 com o tempo os custos da implementação de alterações aumenta, e
 a capacidade do sistema em prestar os serviços esperados diminui
 Complexidade:
 difícil de desenvolver: um único desenvolvedor não é capaz de
entender o sistema como um todo
 difícil de usar
 difícil de entender: código incompreensível, falta de documentação
Introdução ao Teste de Software 4
Introdução
 Garantia de Qualidade de Software
 Aplicação de métodos e ferramentas técnicas
 Realização de revisões técnicas e inspeções
 Atividades de testes
 em complemento às revisões e outras técnicas
 Verificação e Validação
 Aplicação de padrões
Introdução ao Teste de Software 5
Introdução
 Garantia de Qualidade de Software
Validação: Assegurar que o produto final 
corresponda aos requisitos do software
Verificação: Assegurar consistência, 
completitude e corretitude do produto em 
cada fase e entre fases consecutivas do ciclo 
de vida do software
Introdução ao Teste de Software 6
Estamos construindo o produto certo?
Estamos construindo corretamente o produto?
Projetistas de software experientes 
dizem:
“A atividade de teste nunca termina; 
ela apenas é transferida do projetista 
(você) para o seu cliente. Toda vez 
que o seu cliente usa o programa, um 
teste é realizado”
7
Introdução
8
Padrões Típicos Indústria de Software
 Ordem de 10 erros por KDSI (1000 linhas de 
código fonte liberadas)
 Softwares de alta qualidade apresentam da ordem 
de 0.1 erro por KDSI
 Um observação importante é que a maioria 
desses erros encontra-se em partes do código 
raramente executadas
Introdução
Objetivos
 O objetivo do processo de testes de programas é
descobrir erros no programa
 Um bom teste é o que apresenta alta probabilidade de
encontrar um “novo” erro.
 Um teste bem sucedido é o que descobre um erro ainda
não descoberto.
“Testes não asseguram a ausência de erros, eles
apenas podem assegurar a presença de
erros”. (Dijkstra).
9
Evitando erros
 Estudos demonstraram que boas práticas de programação
diminuem o número de erros cometidos na codificação de
programas:
 uso extensivo de brancos no código
 inclusão de comentários
 aderência às regras de nomeação de variáveis
 utilizar indentação - facilita a visualização
 Planejamento de ambiente para testes - convém ser feito desde o
início das atividades
10
Terminologia
 Defeito Erro Falha
 Defeito: deficiência mecânica ou algorítmica que, se 
ativada, pode levar a uma falha
 Erro: item de informação ou estado de execução 
inconsistente
 Falha: evento notável em que o sistema viola suas 
especificações
Introdução ao Teste de Software 11
Terminologia
 Teste
 Depuração
Introdução ao Teste de Software 12
Processo de executar um programa com
o objetivo de revelar a presença de defeitos; ou, falhando nesse 
objetivo, aumentar a confiança sobre o programa.
Conseqüência não previsível do teste.
Após revelada a presença do defeito, ele
deve ser encontrado e corrigido.
Tipos de erros
 Erros de compilação - resultado de código construído
de forma incorreta: digitação errada, falta de
pontuação, abertura de blocos sem os fechamentos
correspondentes, falta de protótipos de funções etc.
 Erros de execução - os que ocorrem durante a
execução do programa, detectados pelo ambiente de
execução: ponteiros não iniciados, divisão por zero.
 Erros de lógica - o programa não executa da forma
como deveria; apesar de não conter erros de código
nem produzir erros na execução, não funciona
corretamente, produzindo resultados errados.
13
Defeitos no Processo
de Desenvolvimento
 A maior parte é de origem humana
 São gerados na comunicação e na transformação de 
informações
 Continuam presentes nos diversos produtos de 
software produzidos e liberados (10 defeitos a cada 
1000 linhas de código)
 A maioria encontra-se em partes do código raramente 
executadas
Introdução ao Teste de Software 14
Defeitos no Processo
de Desenvolvimento
 Quanto antes a presença do defeito for 
revelada, menor o custo de correção do 
defeito e maior a probabilidade de 
corrigi-lo corretamente
 Principal causa: tradução incorreta de 
informações
 Solução: introduzir atividades de 
Verificação,Validação e Teste ao longo de 
todo o ciclo de desenvolvimento
15
Tipos de Defeitos
 Omissão
 Algum requisito importante relacionado à
funcionalidade, ao desempenho, às restrições de
projeto, a atributos ou a interface externa não foi
incluído;
 Não está definida a resposta do software para
todas as possíveis situações de entrada de dados;
 Faltam seções na especificação de requisitos;
 Faltam referências de figuras, tabelas e
diagramas;
 Falta definição de termos e unidades de medida.
16
Tipos de Defeitos
 Exemplo de Omissão
 Requisitos:
1. Livros podem ser emprestados para professores,
funcionários e alunos.
2. O prazo de devolução para alunos é de 5 dias.
3. O prazo de devolução para professores é de 10 
dias.
4. Dependendo da categoria do livro, o prazo 
poderá ser maior.
 Quais os defeitos nestes requisitos?
 Qual o prazo de devolução para funcionários?
 Quais as categorias possíveis?
 Quais os prazos diferenciados para cada 
categoria?
17
Tipos de Defeitos
 Ambiguidade
 Um requisito tem várias interpretações
devido a diferentes termos utilizados para
uma mesma característica ou vários
significados de um mesmo termo para um
contexto em particular.
18
Tipos de Defeitos
 Exemplo de ambiguidade
 Requisitos:
 A multa será cobrada apenas de usuários do tipo
aluno e professor.
 Qual o defeito neste requisito?
 Duas interpretações podem ser tiradas deste
requisito devido ao uso incorreto do “e”:
 A multa será cobrada tanto de professores 
quanto de alunos;
 A multa será cobrada apenas de professores que
também forem alunos;
19
Tipos de Defeito
 Inconsistência
 Dois ou mais requisitos são conflitantes.
 Exemplo de inconsistência:
 É permitido no máximo 10 renovações de um
mesmo livro.
 Alunos podem permanecer com o mesmo livro
por no máximo um semestre.
 Qual o defeito nestes requisitos?
 Inconsistências entre os períodos máximos de
empréstimo nos dois requisitos.
20
Tipos de Defeitos
 Fato incorreto
 Um requisito descreve um fato que não é
 verdadeiro, considerando as condições
 solicitadas para o sistema.
 Informação estranha
 As informações fornecidas no requisito não
são necessárias ou mesmo usadas.
21
Estratégias de Teste
 Software é testado para se descobrir erros de
projeto e construção.
 Uma estratégia de teste de software fornece um
roteiro que deve responder a questões do tipo:
– Quais os passos a serem conduzidos como parte do teste?
– Quando os passos são planejados e executados?
– O programa deve ser testado como um todo ou em 
partes?
– Testes que já foram conduzidos devem ser reexecutados
quando o software é modificado?
– Quando o cliente deve ser envolvido?
22
Estratégias de testes
 Os testes devem se iniciar no nível de módulos ou de
classes (na OO) e prosseguir através da integraçãodos
módulos
 O teste de um sistema de software é um processo e
diferentes técnicas podem ser aplicadas ao longo deste
processo
 O teste deve ser desenvolvido pelo implementador do
software e, se o sistema for grande, por uma equipe de
testes independente
 Existem inúmeras etapas no processo de depuração de um
sistema: testes de módulo, de integração, de validação, de
esforço etc.
23
Organização dos testes
 Conflito de interesses
– O desenvolvedor tem interesse em demonstrar que o programa 
está livre de erros e que funciona de acordo com os requisitos.
– Assim, o desenvolvedor projeta e executa testes que demonstram 
que o programa funciona, em vez de descobrir erros.
– Um grupo de teste independente não tem esse conflito.
 Concepções equivocadas
– Os desenvolvedores não devem fazer nenhum teste.
– O grupo de teste independente (ITG) deve se envolver com o 
projeto somente quando os passos de teste estão para começar.
 Organização recomendada
– O desenvolvedor testa as unidades individuais e faz testes de
integração até a arquitetura do software estar completa.
– Depois, o ITG trabalha junto com o desenvolvedor para garantir
que testes rigorosos serão conduzidos.
24
Estratégia de Teste
Estratégia de Teste Processo de 
Desenvolvimento
Teste de Unidade Código-fonte
Teste de Integração Projeto e Construção
Teste de Validação Requisitos
Teste de Sistema Engenharia de Sistemas
25
Direção do 
Teste
Teste de Unidade
 Concentra-se no módulo
 Utiliza a técnica de teste estrutural (caixa 
branca)
 Pode ser realizado em paralelo para 
vários
módulos
26
Teste de unidade
27
Interface 
Estruturas lógicas de dados
Condições-limites
Caminhos independentes
Caminho de manipulações de
erros
Módulo 
testado
Casos de teste
Teste de unidade -
Procedimentos
 Geralmente, um programa não é um 
módulo
único, mas formado de diversos módulos 
que,
para efeito do teste de unidade devem 
ser
testados separadamente
28
Teste de Unidade - Procedimentos
29
Modulo
stub stub
driver
driver : é um “programa principal” que 
aceita dados de casos de teste, passa 
esses dados para o módulo a ser testado 
e imprime os dados relevantes que ele 
recebe do módulo
stub : são módulos que servem para 
substituir outros módulos que estejam 
subordinados, isto é, que são chamados 
pelo módulo testado; ele usa a interface 
do módulo subordinado, faz o mínimo de 
manipulação de dados, imprime uma 
verificação da entrada e retorna
Resultado
Teste de Integração
 Constrói-se, de uma forma sistemática, a estrutura do
programa realizando, ao mesmo tempo, testes para
detectar erros de interface
 Embora os módulos, depois do teste de unidade,
funcionem corretamente de forma isolada, o teste de
integração é necessário pois quando colocados juntos,
várias situações inesperadas podem acontecer
 Integração dos módulos é feita através de uma
abordagem incremental
 integração top-down (descendente)
 integração bottom-up (ascendente)
30
Teste de Integração
 Integração Top-down
 a integração dos módulos é feita de cima para baixo
 pode ser realizada de duas maneiras:
 por profundidade (M2, M5 e M8 ou M2, M5, M6 e M9)
 por largura (M2, M3 e M4)
31
M5
M3 M4
M9M8
M2
M7M6
M1
Teste de Integração
 Integração Top-down
 O processo de integração é feito através de cinco 
passos:
1. o módulo de controle principal é usado como um 
driver e substitui-se por stubs todos os módulos 
reais diretamente subordinados ao módulo principal
2. dependendo da abordagem de integração a ser 
utilizada – por profundidade ou largura – os stubs
são substituídos pelos módulos reais, um de cada 
vez
3. são realizados testes para cada módulo que seja 
integrado;
4. quando um teste é concluído, outro stub é 
substituído pelo módulo real
5. teste de regressão, isto é, repetição de todos ou 
alguns dos testes já realizados pode ser aplicado 
novamente para garantir que novos erros não 
tenham sido introduzidos
32
Teste de Integração
 Integração Top-down por profundidade: permite que 
uma função específica do módulo principal possa ser 
testada por completo
 Nem sempre a construção de um stub é uma tarefa 
fácil, pois se a função do módulo real que ele 
representa for complexa, o stub tem que tratar os 
aspectos principais desse módulo para que o teste seja 
significativo
33
Teste de Integração
 Integração Bottom-up
 a integração dos módulos é feita de baixo para cima 
 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 construção de stubs
34
M5
M3 M4
M9M8
M2
M7M6
M1
“cluster”
Teste de Integração
 Integração Bottom-up
 o processo de integração é feito através de quatro passos:
1. os módulos de nível mais baixo são combinados em 
clusters
que executam funções específicas do módulo 
principal;
2. para cada cluster é elaborado um driver que coordena 
a entrada e saída dos casos de teste;
3. o cluster é testado;
4. os drivers são substituídos pelos clusters que passam a 
interagir com os módulos acima, na estrutura do 
programa.
35
Teste de Integração
 A escolha por uma dessas duas abordagens de integração depende 
do tipo de software e, às vezes, do cronograma do projeto
 Em geral, uma integração combinada - sanduíche - é mais 
aconselhável:
 módulos superiores abordagem top-down
 módulos mais inferiores abordagem bottom-up
 Top-down
 vantagem: testar logo no início as funções principais do 
software
 desvantagem: os stubs e a dificuldade de teste quando eles são 
usados
 Bottom-up
 vantagem: não se precisa de stubs
 desvantagem:o módulo principal não existe enquanto todos 
módulos não estiverem testado
36
Teste de Integração - Documentação
 Documento de especificação de teste
– Plano de teste global para integração do
software
– Descrição dos testes específicos
 É um produto de trabalho e torna-se parte da 
configuração de software.
37
Teste de Regressão
 Toda vez que um novo módulo é adicionado como parte
do teste de integração, o software se modifica.
– Novos caminhos de fluxos de dados são estabelecidos.
– Nova E/S pode ocorrer.
– Nova lógica de controle é adicionada
 Essas modificações podem ser causadas problemas com funções que 
previamente funcionavam corretamente.
 O teste de regressão é a re-execução de algum subconjunto de testes 
que já foi conduzido para garantir que as modificações não ntroduzam
efeitos colaterais indesejáveis.
38
Teste de Regressão
 Pode ser conduzido manualmente ou usando ferramentas 
automatizadas de captação/reexecução.
– Permitem ao engenheiro de software captar casos de teste e 
resultados para reexecução e comparação.
 À medida que o teste de integração prossegue, o número de 
testes de regressão pode crescer significativamente.
– A suíte de testes de integração deve ser projetada para incluir 
apenas testes que cuidam das principais funções do 
programa.
39
Módulos Críticos
 Um módulo crítico tem uma ou mais das seguintes características:
– Aborda vários requisitos do software.
– Está num alto nível da estrutura de controle.
– É complexo ou propenso a erro.
– Tem requisitos de desempenho bem definidos.
 Módulos críticos devem ser testados tão cedo quanto possível.
 Testes de regressão devem ser focados na função de módulos 
críticos.
40
Teste Fumaça
 É uma estratégia de integração constante.
 O software é reconstruído e testado diariamente para dar aos 
gerentes e desenvolvedores uma avaliação realística do 
progresso.
41
Atividades do Teste Fumaça
 Componentes de software são integrados em uma “construção”.
– Inclui todos os dados, bibliotecas, módulos reusáveis e 
componentes que são necessários para implementar uma função 
do produto.
 Uma série de testes é projetada para expor erros que impeçam a 
construção de desempenhar adequadamente a sua função.– Propósito principal: descobrir erros “bloqueadores” que tem a 
maior chance de atrasar o cronograma.
 A construção é integrada com outras construções e o produto inteiro 
é testado diariamente.
– Pode ser usada uma abordagem descendente ou ascendente.
42
Benefícios do Teste Fumaça
 O risco de integração é minimizado.
– Incompatibilidades e outros erros de bloqueio são descobertos logo no 
início, evitando impactos no cronograma.
 A qualidade do produto final é aperfeiçoada.
– Descobre tanto erros funcionais quanto defeitos de projeto 
arquitetural.
 Diagnóstico e correção de erros são simplificados.
– O software que acabou de ser adicionado às construções é uma causa 
provável do erro recém-descoberto.
 Progresso é fácil de avaliar.
– A cada dia que passa, mais é integrado ao software e mais se pode 
demonstrar que ele funciona
43
Teste de Validação
 O software está montado como um pacote e a validação do mesmo 
é realizada através de uma série de testes caixa preta
 Finalidade:
 demonstrar a conformidade aos requisitos funcionais e
de desempenho
 verificar se a documentação está correta
 Duas possibilidades:
 aceito
 não está totalmente de acordo com os requisitos:
negociar com o usuário
44
Teste de Validação
 Engloba o Teste de Aceitação: realizado pelo
próprio usuário
 No caso de software desenvolvido para vários
usuários:
 teste alfa: realizado pelo usuário no ambiente do
desenvolvedor
 teste beta: realizado pelo usuário em seu próprio
ambiente
45
Teste de Sistema
 Considera o software dentro do seu ambiente mais 
amplo (todos os aspectos de interação com ele, 
como outro hardware, software, pessoas, etc.)
 Corresponde a uma série de testes que tem por 
objetivo verificar se todos os elementos do sistema 
foram integrados adequadamente e realizam 
corretamente suas funções:
 teste de segurança: tem por objetivo verificar se todos os 
mecanismos de proteção protegem realmente o software 
de acessos indevidos.
 teste de estresse: tem por objetivo confrontar os 
programas com
situações anormais de freqüência, volume ou recursos em 
quantidade.
 teste de desempenho: tem por objetivo testar o tempo de 
resposta do sistema e é aplicado, geralmente, para 
sistemas de tempo real
46
Referências bibliográficas
 Pressman, R. S. Engenharia de Software. Makron Books
 Sommerville, I. Engenharia de Software.
47