Capítulo 22 - Teste de Software

Prévia do material em texto

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 1
Chapter 22
 Software Testing Strategies
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 8/e 
by Roger S. Pressman and Bruce R. Maxim
Slides copyright © 1996, 2001, 2005, 2009, 2014 by Roger S. Pressman
For non-profit educational use only
May be reproduced ONLY for student use at the university level when used in conjunction 
with Software Engineering: A Practitioner's Approach, 8/e. Any other reproduction or use is 
prohibited without the express written permission of the author.
All copyright information MUST appear if these slides are posted on a website for student 
use.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 2
Testando Software
O teste é o processo de realização 
de um programa com a intenção 
específica de detecção de erros 
antes da entrega ao utilizador final.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 3
O Que Teste de Software Mostra
erroserros
Os requisitos de conformidadeOs requisitos de conformidade
performanceperformance
uma indicação uma indicação 
da qualidadeda qualidade
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 4
Abordagem Etratégica
 Para realizar o teste eficaz, você deve conduzir eficazes 
revisões técnicas. Ao fazer isso, muitos erros serão 
eliminados antes do ensaio.
 O teste começa no nível do componente e trabalha "para 
fora" para a integração de todo o sistema baseado em 
computador. 
 Diferentes técnicas de teste são apropriados para 
diferentes abordagens de engenharia de software e em 
diferentes pontos no tempo.
 O teste é realizado pelo desenvolvedor do software e 
(para grandes projetos) um grupo de teste independente.
 Teste e depuração são atividades diferentes, mas a 
depuração devem ser acomodados em qualquer 
estratégia de ensaio. 
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 5
Verificação & Validação
 Verificação refere-se ao conjunto de tarefas que 
asseguram que o software implementa 
corretamente uma função específica.
 Validação refere-se a um conjunto diferente de 
tarefas que asseguram que o software que foi 
construído é rastreável aos requisitos do cliente. 
Boehm [Boe 81] afirma isso de outra forma:
 Verificação: "Estamos construindo o produto certo?"
 Validação: "Estamos construindo corretamente o 
produto?"
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 6
Quem Testa o Software?
DesenvolvedorDesenvolvedor Testador IndependenteTestador Independente
Entende o SistemaEntende o Sistema
Mas, vai testar com “CUIDADO”Mas, vai testar com “CUIDADO”
E, é dirigido pela “entrega” E, é dirigido pela “entrega” 
Deve aprender sobre o SistemaDeve aprender sobre o Sistema
Mas, tentará quebrá-lo Mas, tentará quebrá-lo 
E, é orientado pela qualidadeE, é orientado pela qualidade
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 7
Estratégia de Teste
Engenharia de Sist.
Modelagem de Análise
Projeto de Modelagem
Geração de Código Teste Unitário
Teste de Integração
Teste de Validação
Teste de Sistema
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 8
Estratégia de 
Testes
 Nós começamos pelo ‘teste no pequeno’ e em 
seguida em direção ao ‘teste no grande’
 Para o software “convencional”
 O módulo (componente) é nosso foco inicial
 Seguida da Integração dos módulos
 Para Software OO
 Nosso foco quando “teste no pequeno” muda de um 
módulo individual(a visão convencional) para uam 
classe OO que engloba atributos e operações e 
implica a comunicação e a colaboração
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 9
Questões 
Estratégicas
 Especificar os requisitos do produto de forma quantificável, 
muito antes do ensaio.
 Objetivos do teste de estado explicitos
 Compreender os usuários do software e desenvolver um perfil 
para cada categoria de usuário.
 Desenvolver um plano de teste que enfatiza a "testes de ciclo 
rápido."
 Construir software "robusto" que é projetado para testar a si 
mesmo
 Use ténicas de revisões eficazes como um filtro antes do teste
 Conduzir revisões técnicas para avaliar a estratégia de teste e 
os próprios casos de teste.
 Desenvolver uma abordagem de melhoria contínua para o 
processo de teste.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 10
Teste Unitário
modulomodulo
a sera ser
testadotestado
Casos de TesteCasos de Teste
resultadosresultados
Engenheiro de Engenheiro de 
SoftwareSoftware
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 11
Teste Unitário
interface interface 
estruturas de dados locaisestruturas de dados locais
condições de fronteiracondições de fronteira
caminhos independentescaminhos independentes
caminhos de tratamento caminhos de tratamento 
de errosde erros
módulomódulo
a ser a ser 
testadotestado
Casos de testeCasos de teste
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 12
Ambiente de Teste Unitário
MóduloMódulo
stubstub stubstub
ControladorControlador
RESULTADOSRESULTADOS
InterfaceInterface
Estrutura de dados Estrutura de dados 
LocaisLocais
Condições de FronteiraCondições de Fronteira
Caminhos Caminhos 
IndependentesIndependentes
Caminho de Tratamento Caminho de Tratamento 
de Errosde Erros
Casos de TesteCasos de Teste
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 13
Estratégias de Testes de Integração
Opções:Opções:
•• A abordagem “big bang”A abordagem “big bang”
•• uma estratégia de construção gradualuma estratégia de construção gradual
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 14
Top Down Integration
módulo superior é testada commódulo superior é testada com
stubsstubs
stubs são substituídos umstubs são substituídos um
 de cada vez , "Primeira aprofundamento”de cada vez , "Primeira aprofundamento”
como novos módulos são integrados,como novos módulos são integrados,
um subconjunto de testes é executado um subconjunto de testes é executado 
novamentenovamente
AA
BB
CC
DD EE
FF GG
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 15
Integração Bottom-Up
Controladores são substituídos umControladores são substituídos um
De cada vez, "primeira profundidadeDe cada vez, "primeira profundidade
módulos de trabalho são agrupados emmódulos de trabalho são agrupados em
compilações e integradoscompilações e integrados
AA
BB
CC
DD EE
FF GG
GrupoGrupo
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 16
TesteSandwich
Principais módulos sãoPrincipais módulos são
testado com stubstestado com stubs
módulos de trabalho são agrupados emmódulos de trabalho são agrupados em
Compilações e integradosCompilações e integrados
AA
BB
CC
DD EE
FF GG
GrupoGrupo
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 17
Teste de Regressão
 Teste de Regressão é a re-execução de alguns subconjuntos 
de testes que já foram realizados para assegurar que as 
alterações não foram propagados efeitos colaterais 
indesejados
 Sempre que o software foi corrigido, algum aspecto da 
configuração do software (programa, sua documentação, 
ou os dados que o suportam) é alterado.
 Testes de Regressão ajuda a garantir que as mudanças 
(devido a testes ou por outras razões) não apresentam 
comportamento não intencional ou erros adicionais.
 testes de regressão podem ser realizados manualmente, 
por re-execução de um subconjunto de todos os casos de 
teste ou usando ferramentas de captura / reprodução 
automatizadas.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 18
Teste de Fumaça
 Uma abordagem comum para a criação de "compilações diárias" 
para o software do produto
 Passos para Teste de Fumaça:
 Componentes de software que foram traduzidos em código são 
integradas numa "construção".
• A compilação inclui todos os dados de arquivos, bibliotecas, módulos 
reutilizáveis, e componentes de engenharia que são necessários para 
implementar uma ou mais funções do produto.
 Uma série de teste é projetada para expor erros que vai manter a 
construção de funções executando adequadamente.
• A intenção deve ser para descobrir erros "rolha" que têm a maior 
probabilidade de lançar o projeto de software atrasado.
 A compilação é integrada com outras compilações e todo o produto 
(em seu formato atual) é testado diariamente.
• A abordagem de integração pode ser de cima para baixo ou de baixo para 
cima..
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 19
Critérios de Teste Geral
 Interface de Integridade – interfaces do módulo internos e 
externos são testados conforme cada módulo ou conjunto é 
adicionada ao software
 Validade Funcional – teste para revelar defeitos funcionais no 
software
 Conteúdo de Informação - teste para erros em estruturas de 
dados locais ou globais
 Performance – Testar limites para verificar o desempenho 
específico
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 20
Teste Orientado à Objetos
 Começa por avaliar a exatidão e consistência 
dos modelos de Análise e Projeto
 Mudanças de Estratégia de Teste
 O conceito de "unidade" amplia devido ao 
encapsulamento
 Integração concentra-se em classes e sua execução 
através de um 'processo' ou no contexto de um 
cenário de uso v
 Validação usa métodos convencionais de Caixa Preta
 Projeto de Caso de Teste baseia-se em métodos 
convencionais, mas também abrange 
características especiais
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 21
Ampliando o a Visão do "Teste"
Pode-se Pode-se argumentarargumentar que a revisão da análise OO que a revisão da análise OO e e 
modelos de projeto são especialmente úteismodelos de projeto são especialmente úteis porque porque 
as mesmas construções semânticasas mesmas construções semânticas (por exemplo, (por exemplo, 
classes, atributos, operações, mensagensclasses, atributos, operações, mensagens) aparecem ) aparecem 
na análise, no projeto e em nível de código. na análise, no projeto e em nível de código. 
• Portanto, um problema na definição de Portanto, um problema na definição de 
atributos de classe que é descoberto durante a atributos de classe que é descoberto durante a 
análise vai contornar os efeitos colaterais que análise vai contornar os efeitos colaterais que 
podem ocorrer se os problemas não foram podem ocorrer se os problemas não foram 
descobertos até de design ou de código (ou descobertos até de design ou de código (ou 
mesmo a próxima iteração da análise).mesmo a próxima iteração da análise).
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 22
Testando o Modelo CRC
1. Revisitar o modelo CRC e o modelo de relaciomaneto de objetos.1. Revisitar o modelo CRC e o modelo de relaciomaneto de objetos.
2. Verifique se a descrição de cada índice de cartão CRC para 2. Verifique se a descrição de cada índice de cartão CRC para 
determinar se uma responsabilidade delegada faz parte da determinar se uma responsabilidade delegada faz parte da 
definição do colaborador.definição do colaborador.
3. Inverta a conexão para assegurar que cada colaborador que é 3. Inverta a conexão para assegurar que cada colaborador que é 
feita para o serviço está a receber solicitações de uma fonte feita para o serviço está a receber solicitações de uma fonte 
razoável.razoável.
4. Usando as conexões invertidas examinadas no passo 3, 4. Usando as conexões invertidas examinadas no passo 3, 
determinar se outras classes pode ser necessário ou se as determinar se outras classes pode ser necessário ou se as 
responsabilidades estão devidamente agrupadas entre as classes.responsabilidades estão devidamente agrupadas entre as classes.
5. Determine se responsabilidades amplamente solicitadas podem 5. Determine se responsabilidades amplamente solicitadas podem 
ser combinadas em uma única responsabilidade.ser combinadas em uma única responsabilidade.
6. Passos 1 a 5 são aplicados de forma iterativa para cada classe e 6. Passos 1 a 5 são aplicados de forma iterativa para cada classe e 
através de cada evolução do modelo de análise.através de cada evolução do modelo de análise.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 23
Teste de Estratégia OO
 teste de classe é o equivalente de teste de 
unidade
 Operações dentro das classes são testadas
 O comportamento do estado da classe é examinado
 Integração aplicada em três diferentes 
estratégias
 Teste baseado em Thread - integra o conjunto de 
classes necessárias para responder a uma entrada ou 
evento;
 Teste baseado em caso de uso - integra o conjunto de 
classes necessárias para responder a um caso de uso;
 Conjunto de testes (Cluster) - integra o conjunto de 
classes necessárias para demonstrar uma colaboração
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 24
Teste de Aplicativos Web - I
 O modelo de conteúdo para o WebApp é revisado 
para descobrir erros. 
 O modelo de interface é revisto para assegurar que 
todos os casos de utilização podem ser acomodados. 
 O modelo de projeto para o WebApp é revisado para 
descobrir erros de navegação.
 A interface de usuário é testaao para descobrir erros 
na apresentação e / ou mecânica de navegação.
 Cada componente funcional é uma unidade testada.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 25
Teste de Aplicativos Web - II
 A navegação ao longo da arquitetura é testada.
 O WebApp é implementado numa variedade de 
configurações ambientais diferentes, e é testada para 
compatibilidade com cada configuração.
 Testes de segurança são realizadas em uma tentativa de 
explorar vulnerabilidades no WebApp ou dentro de seuambiente.
 Os testes de desempenho são conduzidos.
 O WebApp é testado por uma população controlada e 
monitorada dos utilizadores finais.
 Os resultados de sua interação com o sistema são 
avaliados para conteúdo e navegação erros, questões de 
usabilidade, as preocupações de compatibilidade e 
confiabilidade WebApp e desempenho.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 26
Teste de Aplicativos Móveis
 Testando experiência de Usuário – garantindo se app atende 
usabilidade das partes interessadas e as expectativas de 
acessibilidade;
 Testando Compatibilidade de Dispositivos – testes em 
múltiplos dispositivos;
 Testando Desempenho – teste de requisitos não funconais;
 Teste de Conectividade – teste da capacidade do app para 
conexão confiável;
 Teste de Segurança – garantia de que o app atenda às 
expectativas das partes interessadas;
 Testando em estado selvagem – testando aplicativo em 
dispositivos de usuários em ambientes reais do usuário
 Teste de Certificação – app atende aos padrões de 
distribuição
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 27
Teste de Alta Ordem
 Teste de Validação
 Foco é nos requisitos do software
 Teste de Sistema
 Foco é na integração do sistema
 Testando Alpha/Beta
 Foco é no uso do cliente
 O teste de recuperação
 Força o software a falhar de várias maneiras e verifica que a recuperação é 
realizada adequadamente
 Teste de segurança
 Verifique que mecanismos de proteção do sistema protegerá, de fato, de 
entradas impróprias (invasão)
 Teste de Stress
 Executa um sistema de uma forma que exija recursos em quantidade de 
frequência ou de volume anormais
 Teste de desempenho
 testar o desempenho do tempo de execução de software dentro do contexto 
de um sistema integrado
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 28
Depuração: Um Diagnóstico do Processo
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 29
O processo de depuração
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 30
Esforço da Depuração
tempo requeridotempo requerido
para diagnosticar opara diagnosticar o
sintomas esintomas e
determinar odeterminar o
causacausa
tempo requeridotempo requerido
para corrigir o erropara corrigir o erro
e de condução e de condução 
testes de regressãotestes de regressão
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 31
Causas & Sintomas
sintomasintoma
causacausa
sintoma e causa pode sersintoma e causa pode ser
geograficamente separadosgeograficamente separados
sintoma pode desaparecer sintoma pode desaparecer 
Quando outro problema é Quando outro problema é 
consertadoconsertado
causa pode ser devida a causa pode ser devida a 
uma combinação de falhasuma combinação de falhas
causa pode ser devida a um causa pode ser devida a um 
sistema ou um erro do compiladorsistema ou um erro do compilador
causa pode ser devido a causa pode ser devido a 
pressupostos que todo pressupostos que todo 
mundo acreditamundo acredita
sintoma pode ser intermitentesintoma pode ser intermitente
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 32
Consequências dos Bugs
dano
suave irritante
perturbador
sério
extremo
catastrófico
infectados
Tipo de Bug
Categorias de Bugs: erros relacionadas Categorias de Bugs: erros relacionadas 
com a função, bugs relacionados com o com a função, bugs relacionados com o 
sistema, erros de dados, erros de sistema, erros de dados, erros de 
codificação, erros de projeto, erros codificação, erros de projeto, erros 
de documentação, violações de normas, etc.de documentação, violações de normas, etc.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 33
Técnicas de Depuração
Força bruta / teste
Backtracking
Indução
Dedução
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 34
Corrigindo o Erro
 É a causa do bug reproduzido em outra parte do programa? Em 
muitas situações, um defeito de programa é causada por um 
padrão errôneo de lógica que pode ser reproduzido em outro 
lugar.
 O "próximo grande" pode ser introduzido pela correção que estou 
prestes a fazer? Antes da correcção ser feita, o código de fonte 
(ou, melhor, o projeto) deve ser avaliadopara determinar o 
acoplamento de estruturas lógicas e de dados. 
 O que poderíamos ter feito para evitar este erro, em primeiro lugar? 
Esta questão é o primeiro passo para estabelecer uma 
abordagem de garantia de qualidade de software estatístico. Se 
corrigir o processo, bem como o produto, o erro for removido a 
partir do programa atual e pode ser eliminado a partir de 
todos os futuros programas.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e 
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 35
Pensamentos Conclusivos
 Pense – antes do ato da correção
 Use ferramentas para obter informações 
adicionais
 Se você está em um impasse, peça ajuda de 
outra pessoa
 Uma vez corrigido o erro (bug), use teste 
regressivo para descobrir quaisquer efeitos 
colaterais.
	Chapter 22
	Software Testing
	What Testing Shows
	Strategic Approach
	V & V
	Who Tests the Software?
	Testing Strategy
	Slide 8
	Strategic Issues
	Unit Testing
	Slide 11
	Unit Test Environment
	Integration Testing Strategies
	Top Down Integration
	Bottom-Up Integration
	Sandwich Testing
	Regression Testing
	Smoke Testing
	General Testing Criteria
	Object-Oriented Testing
	Broadening the View of “Testing”
	Testing the CRC Model
	OO Testing Strategy
	WebApp Testing - I
	WebApp Testing - II
	MobileApp Testing
	High Order Testing
	Debugging: A Diagnostic Process
	The Debugging Process
	Debugging Effort
	Symptoms & Causes
	Consequences of Bugs
	Debugging Techniques
	Correcting the Error
	Final Thoughts