SlideShare une entreprise Scribd logo
1  sur  35
Télécharger pour lire hors ligne
Testes de Software
Fases
Baseado em notas de aula da profa. Eliane Martins
Tópicos
• Testes de Unidades
• Testes de Integração
• Testes de Aceitação e de Sistemas
• Testes de Regressão
Testes de Unidades
Visam exercitar detalhadamente uma unidade do sistema:
módulo ou função; classe ou pequenos “clusters”
Aspectos a serem considerados :
interfaces: verificar parâmetros de entrada e saída
estruturas de dados: verificar integridade dos dados
armazenados
condições de limite: verificar se a unidade opera
adequadamente nos limites estabelecidos
tratamento de erros
Componentes de testes-1
Unidade
em
Teste
Componentes de testes-2
Necessários quando se testam unidades isoladamente.
Podem ser:
driver (controlador): chama a unidade em teste
stub: substitui uma unidade que é chamada
Casos
de teste
Driver
Unidade
em
Teste
Stub 1 Stub 2
resultados
Stub 3
Componentes de testes
devem ser mais simples e mais rápidos de
desenvolver do que as unidades
substituídas
grau de facilidade ou dificuldade de
construí-los depende da qualidade do
projeto
Exemplo: stub
type VetorInt = array [1 .. N] of
integer;
...
procedure Ordena_Vetor (a : VetorInt);
...
begin
write (“Valores fornecidos”);
for i := 1 to N do write (a [ i ] );
write (“Forneça os valores
ordenados”);
for i := 1 to N do read (a [ i ] );
end;
Módulo
A
Módulo
Ordena_Vetor
vetor
desordenado
vetor
ordenado
stub para este procedimento ?
Exemplo - Driver
Driver
Módulo
insereItem
Módulo
criaTab
Módulo
leItem
Módulo
mostraTab
type TabInt = array [ 1 .. N, 1 .. M ] of
integer;
...
var Tabela: TabInt,
x: integer;
...
criaTab ;
leItem ( x );
insereItem (x );
mostraTab ;
....
Testes de integração
Integram unidades já testadas
critério: exercitar cada unidade pelo menos
uma vez
Falhas de integração
interfaces incorretas
falta, sobreposição ou conflito de funcionalidades
violação da integridade de arquivos e estruturas de dados globais
seqüência incorreta de unidades
tratamento de erros (exceções) incorreto
problema de configuração / versões
falta de recursos para atender a demanda das unidades
objeto incorreto é associado a mensagem (polimorfismo)
Abordagens de integração
Não incremental (“big-bang”):
todas as unidades são integradas de uma só vez
esforço de preparação menor
esforço para diagnóstico e correção de falhas é maior
Incremental
as unidades são integradas gradualmente
descendente (“top-down”)
ascendente (“bottom-up”)
por colaboração
mista
Abordagem incremental
A
B
T1
T2
T3
A
B
T1
T2
T3
T4
C
A
B
T1
T2
T3
T4
T5 C
D
Integração ascendente (“top-down”)
começa com a unidade
principal e vai aos
poucos integrando as
unidades subordinadas
em OO: classes de
controle primeiro
utiliza stubs em lugar
das unidades
subordinadas
Unidade Principal
Subordinada 1
Subordinada 1a
Stub
Integração ascendente (“top-down”)
Pode ser feita em profundidade ou em largura
interfaces de mais alto nível são testadas mais cedo
Unidade Principal
Subordinada 1
Subordinada 1a
Stub
Unidade Principal
Subordinada 1 Subordinada 2
Stub
em profundidade
em largura
Integração descendente (“bottom-up”)
começa a integração pelas
unidades subordinadas
em OO: começar pelas
classes independentes ou
que usam poucas servidoras
utiliza drivers em lugar das
unidades de controle
algoritmos de mais baixo
nível são testados antes de
serem integrados ao resto do
sistema
Subordinada 1a Subordinada 1b
Driver1a Driver1b
Subordinada 1a Subordinada 1b
Unidade 1
Integração por colaborações
identifica colaborações: grupos de unidades que interagem para
realizar uma ação do sistema
escolhe uma colaboração integrando as unidades que a compõem
critério: integrar todas as colaborações identificadas
testes enfocam funcionalidades ⇒ podem ser reutilizados nos
testes de sistema
P1
P3 P5
P2 P4
e1
e2
e3
e4
e5
s1
s2
s3
Integração por colaborações
P3
P2 P4e4 s3
P1
P3 P5
e1
e2
e3 s1
P3 P5
P2 P4e4
e5
s2
s3
teste de 1 colaboração
teste de 1
colaboração com
várias entradas
teste de
várias
colaborações
Testes de sistemas
Combinação de testes que
tem por objetivo:
revelar falhas de sistema
demonstrar que o
sistema em teste
implementa os requisitos
funcionais e não
funcionais
o sistema foi construído
corretamente ?
Fontes de informação para testes
especificação de requisitos
protótipo, layouts ou modelos da IU
políticas da organização
implementadas como objetos de
negócio, “stored procedures” ou
“triggers”
características do produto descritas
na literatura
características e procedimentos
descritos na documentação, telas de
ajuda ou assistentes de operação
(“wizards”)
Especificação deve ser:
• completa
• consistente
• precisa
• testável
Testes dos requisitos funcionais
Visam verificar se as funcionalidades especificadas foram
devidamente implementadas
Uso de métodos de testes caixa-preta :
partição de equivalência
valores-limite
tabela de decisão / grafo causa-efeito
modelos de estado
diagramas de casos de uso
cenários
...
Testes dos requisitos não funcionais
Visam determinar se a implementação do sistema satisfaz aos
requisitos não funcionais
Tipos de testes:
configuração e compatibilidade
desempenho
estresse
tolerância a falhas
segurança
...
Testes de configuração e compatibilidade
Verificam se a implementação é capaz de executar nas diferentes
configurações do ambiente alvo que foram especificadas
Verificam se a implementação é capaz de interoperar com sw e hw
conforme especificado:
sistemas já existentes
plataformas específicas de hw
diferentes (versões de )sistemas operacionais
diferentes interfaces gráficas (X-Windows, Microsoft
Windows)
diferentes API e IDL
diferentes SGBD
Testes de desempenho
Visam determinar se implementação satisfaz aos requisitos de
desempenho especificados:
configuração de rede
tempo de CPU
limitação de memória
carga do sistema
taxa de chegada de entradas
esses requisitos devem ser descritos de forma testável
Exemplo de como expressar requisitos para
testes
• Nro.transações/segundo
• tempo de resposta
• Kbytes
• nro. de chips de RAM
• tempo de treinamento
• número de quadros de ajuda
• tempo médio entre defeitos (failure)
• taxa de ocorrência de defeitos
• disponibilidade
• tempo de reinicialização após defeito
• % de eventos que levam a defeitos
• probabilidade de que dados sejam corrompidos
• % comandos dependentes de plataforma
• número de plataformas-alvo
Desempenho
Tamanho
Usabilidade
Confiabilidade
Portabilidade
Variações dos testes de desempenho
Testes de carga
geralmente associados com sistemas transacionais
usam simuladores de carga para geração de múltiplas
transações/usuários simultâneamente
Testes de volume
geralmente usados para sistemas “batch”
consistem na transmissão de um grande volume de
informações quando o sistema está com a carga normal
Testes de estresse
Visam verificar se o sistema não apresenta um comportamento de
risco quando submetido a carga elevada e com um ou mais
recursos saturados
Importância:
muitos sistemas apresentam comportamento de risco nessa
situação
falhas detectadas são sutis
correções desse tipo de falha podem requerer retrabalho
considerável
Testes da tolerância a falhas
Visam verificar os mecanismos de detecção e recuperação de
erros:
recuperação automática:
mecanismos implementados corretamente ?
tempo de resposta é aceitável ?
Recuperação manual
o tempo médio de reparo é aceitável ?
São realizados usando-se testes por injeção de falhas
Testes de segurança
Visam verificar a capacidade do sistema de impedir acesso não
autorizado, sabotagem ou outros ataques intencionais
Características básicas de segurança são testadas como as outras
funcionalidades (logon/logoff, permissões)
testes adicionais são geralmente feitos por especialistas ou
“hackers” contratados
Testes de validação
Têm os mesmos objetivos que os testes de sistemas, só que
envolvem a participação do cliente ou usuário
Testes alfa:
realizados por um grupo de usuários no ambiente de
desenvolvimento
seu objetivo é determinar se o sistema pode ser liberado
Testes beta
realizados por um grupo de usuários em ambiente de
operação
Testes de aceitação
Testes de validação
Testes de aceitação:
realizados pelo cliente para decidir se aceita ou não o sistema
são realizados de acordo com um plano de aceitação
Testes de conformidade:
visam verificar se a implementação satisfaz à legislação ou a
padrões estabelecidos
podem ser realizados por centros de certificação
Testes de regressão
Testes realizados a cada vez que um sw é
alterado
Objetivo:
validar modificações feitas
mostrar que modificações realizadas não
afetaram as partes não modificadas
isto é
mostrar que o sw não regrediu
Aplicabilidade dos testes de regressão
testar aplicações críticas que devem ser retestadas
freqüentemente
testar sw que é alterado constantemente durante o
desenvolvimento (por exemplo, Processo Incremental)
testar componentes reutilizáveis para determinar se são
adequados para o novo sistema
durante os testes de integração
durante os testes, após correções
em fase de manutenção
para identificar diferenças no comportamento do sistema quando
há mudanças de plataforma (uso de seqüências-padrão ou
“benchmarks”)
Aplicabilidade dos testes de regressão (OO)
quando uma nova subclasse é criada
quando uma super-classe é alterada
quando uma classe servidora é alterada
quando uma classe é reusada em um novo
contexto
Abordagens para os testes de regressão
Retesta tudo:
reaplica todos os testes
Seletiva:
seleciona um subconjunto dos testes aplicados
Em ambos os casos:
alguns testes devem ser atualizados ou novos testes devem ser
acrescentados
Sumário
Testes de integração são úteis mesmo que as unidades tenham
sido testadas
Abordagens de integração incremental são “mais baratas” do
que abordagem não-incremental
Testes de desempenho, estresse e tolerância a falhas devem ser
realizados cedo na fase de testes pois podem implicar em grandes
alterações (talvez de projeto)
Modificações no sw são inevitáveis e introduzem falhas ⇒ testes
aplicados precisam ser armazenados para uso em testes de
regressão

Contenu connexe

Tendances

Talk sobre testes automatizados. Parte 1/2
Talk sobre testes automatizados. Parte 1/2Talk sobre testes automatizados. Parte 1/2
Talk sobre testes automatizados. Parte 1/2Danilo Pinotti
 
TechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test ManagerTechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test ManagerAlan Carlos
 
Noções em teste de software e introdução a automação
Noções em teste de software e introdução a automaçãoNoções em teste de software e introdução a automação
Noções em teste de software e introdução a automaçãoSandy Maciel
 
Teste Dirigido por Modelos
Teste Dirigido por ModelosTeste Dirigido por Modelos
Teste Dirigido por ModelosNatã Melo
 
Workshop - Plano de Testes End to End com o Microsoft Test Manager
Workshop   - Plano de Testes End to End com o Microsoft Test ManagerWorkshop   - Plano de Testes End to End com o Microsoft Test Manager
Workshop - Plano de Testes End to End com o Microsoft Test ManagerAlan Carlos
 
Tecnicas Para Planejamento E Execucao De Testes De Software
Tecnicas Para Planejamento E Execucao De Testes De SoftwareTecnicas Para Planejamento E Execucao De Testes De Software
Tecnicas Para Planejamento E Execucao De Testes De Softwaremarthahuback
 
Testes Funcionais - Unidade IV
Testes Funcionais - Unidade IVTestes Funcionais - Unidade IV
Testes Funcionais - Unidade IVJoão Lourenço
 
Fundamentos de Teste de Software - Dev in PF. por Aline Zanin
Fundamentos de Teste de Software - Dev in PF. por Aline ZaninFundamentos de Teste de Software - Dev in PF. por Aline Zanin
Fundamentos de Teste de Software - Dev in PF. por Aline ZaninDevInPF
 
Testes unitários x unit
Testes unitários   x unitTestes unitários   x unit
Testes unitários x unitLucas Marques
 
Palestra GUTS - Viabilidade da Automacao Teste Software e Demo QTP
Palestra GUTS - Viabilidade da Automacao Teste Software e Demo QTPPalestra GUTS - Viabilidade da Automacao Teste Software e Demo QTP
Palestra GUTS - Viabilidade da Automacao Teste Software e Demo QTPPriscila Coelho S. Blauth
 
Pensando em java univali turbinando seus testes
Pensando em java univali   turbinando seus testesPensando em java univali   turbinando seus testes
Pensando em java univali turbinando seus testesSandro Giacomozzi
 
Test-Driven Development (TDD) utilizando o framework xUnit.net
Test-Driven Development (TDD) utilizando o framework xUnit.netTest-Driven Development (TDD) utilizando o framework xUnit.net
Test-Driven Development (TDD) utilizando o framework xUnit.netRenato Groff
 
UnP Eng. Software - Aula 26
UnP Eng. Software - Aula 26UnP Eng. Software - Aula 26
UnP Eng. Software - Aula 26Hélio Medeiros
 
Engenharia de software testes
Engenharia de software  testesEngenharia de software  testes
Engenharia de software testesAdilmar Dantas
 

Tendances (20)

Talk sobre testes automatizados. Parte 1/2
Talk sobre testes automatizados. Parte 1/2Talk sobre testes automatizados. Parte 1/2
Talk sobre testes automatizados. Parte 1/2
 
TechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test ManagerTechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test Manager
 
Noções em teste de software e introdução a automação
Noções em teste de software e introdução a automaçãoNoções em teste de software e introdução a automação
Noções em teste de software e introdução a automação
 
Teste Dirigido por Modelos
Teste Dirigido por ModelosTeste Dirigido por Modelos
Teste Dirigido por Modelos
 
Workshop - Plano de Testes End to End com o Microsoft Test Manager
Workshop   - Plano de Testes End to End com o Microsoft Test ManagerWorkshop   - Plano de Testes End to End com o Microsoft Test Manager
Workshop - Plano de Testes End to End com o Microsoft Test Manager
 
Plano de teste
Plano de testePlano de teste
Plano de teste
 
Tecnicas Para Planejamento E Execucao De Testes De Software
Tecnicas Para Planejamento E Execucao De Testes De SoftwareTecnicas Para Planejamento E Execucao De Testes De Software
Tecnicas Para Planejamento E Execucao De Testes De Software
 
Testes Funcionais - Unidade IV
Testes Funcionais - Unidade IVTestes Funcionais - Unidade IV
Testes Funcionais - Unidade IV
 
Testes Unitários
Testes UnitáriosTestes Unitários
Testes Unitários
 
Fundamentos de Teste de Software - Dev in PF. por Aline Zanin
Fundamentos de Teste de Software - Dev in PF. por Aline ZaninFundamentos de Teste de Software - Dev in PF. por Aline Zanin
Fundamentos de Teste de Software - Dev in PF. por Aline Zanin
 
Testes unitários x unit
Testes unitários   x unitTestes unitários   x unit
Testes unitários x unit
 
Palestra GUTS - Viabilidade da Automacao Teste Software e Demo QTP
Palestra GUTS - Viabilidade da Automacao Teste Software e Demo QTPPalestra GUTS - Viabilidade da Automacao Teste Software e Demo QTP
Palestra GUTS - Viabilidade da Automacao Teste Software e Demo QTP
 
Pensando em java univali turbinando seus testes
Pensando em java univali   turbinando seus testesPensando em java univali   turbinando seus testes
Pensando em java univali turbinando seus testes
 
Test-Driven Development (TDD) utilizando o framework xUnit.net
Test-Driven Development (TDD) utilizando o framework xUnit.netTest-Driven Development (TDD) utilizando o framework xUnit.net
Test-Driven Development (TDD) utilizando o framework xUnit.net
 
Junit
JunitJunit
Junit
 
UnP Eng. Software - Aula 26
UnP Eng. Software - Aula 26UnP Eng. Software - Aula 26
UnP Eng. Software - Aula 26
 
Mini aula de teste de software
Mini aula de teste de softwareMini aula de teste de software
Mini aula de teste de software
 
Apresentacao teste
Apresentacao testeApresentacao teste
Apresentacao teste
 
Junit 4.0
Junit 4.0Junit 4.0
Junit 4.0
 
Engenharia de software testes
Engenharia de software  testesEngenharia de software  testes
Engenharia de software testes
 

Similaire à Fases testes

Introdução a Automação de Teste de Software
Introdução a Automação de Teste de SoftwareIntrodução a Automação de Teste de Software
Introdução a Automação de Teste de SoftwareCamilo Ribeiro
 
Aplicação de Testes Caixa Branca / Preta. Métodos dos caminhos básicos ou cri...
Aplicação de Testes Caixa Branca / Preta. Métodos dos caminhos básicos ou cri...Aplicação de Testes Caixa Branca / Preta. Métodos dos caminhos básicos ou cri...
Aplicação de Testes Caixa Branca / Preta. Métodos dos caminhos básicos ou cri...Stanley Araújo
 
Gerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxGerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxRoberto Nunes
 
Do push para a produção: Os desafios de automação em Continuous Delivery
Do push para a produção: Os desafios de automação em Continuous DeliveryDo push para a produção: Os desafios de automação em Continuous Delivery
Do push para a produção: Os desafios de automação em Continuous DeliveryCamilo Ribeiro
 
Engenharia de Testes
Engenharia de TestesEngenharia de Testes
Engenharia de TestesUFPA
 
ALM - Testes Manuais no Microsoft Test Manager
ALM - Testes Manuais no Microsoft Test ManagerALM - Testes Manuais no Microsoft Test Manager
ALM - Testes Manuais no Microsoft Test ManagerAlan Carlos
 
Aula12 T EES UFS Testes de SW
Aula12  T EES  UFS  Testes de SWAula12  T EES  UFS  Testes de SW
Aula12 T EES UFS Testes de SWguest8ae21d
 
Introdução à Engenharia de Testes de Software
Introdução à Engenharia de Testes de SoftwareIntrodução à Engenharia de Testes de Software
Introdução à Engenharia de Testes de SoftwareCloves da Rocha
 
Testes De Software - Uma Visão Geral
Testes De Software - Uma Visão GeralTestes De Software - Uma Visão Geral
Testes De Software - Uma Visão Geralpaulo peres
 
Desenvolvimento Dirigido por Testes
Desenvolvimento Dirigido por TestesDesenvolvimento Dirigido por Testes
Desenvolvimento Dirigido por TestesCamilo Ribeiro
 
4 engenharia de software
4   engenharia de software4   engenharia de software
4 engenharia de softwareFelipe Bugov
 

Similaire à Fases testes (20)

Introdução a Automação de Teste de Software
Introdução a Automação de Teste de SoftwareIntrodução a Automação de Teste de Software
Introdução a Automação de Teste de Software
 
Overview de QA
Overview de QA Overview de QA
Overview de QA
 
Aplicação de Testes Caixa Branca / Preta. Métodos dos caminhos básicos ou cri...
Aplicação de Testes Caixa Branca / Preta. Métodos dos caminhos básicos ou cri...Aplicação de Testes Caixa Branca / Preta. Métodos dos caminhos básicos ou cri...
Aplicação de Testes Caixa Branca / Preta. Métodos dos caminhos básicos ou cri...
 
Unit Testing
Unit TestingUnit Testing
Unit Testing
 
Gerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxGerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptx
 
Do push para a produção: Os desafios de automação em Continuous Delivery
Do push para a produção: Os desafios de automação em Continuous DeliveryDo push para a produção: Os desafios de automação em Continuous Delivery
Do push para a produção: Os desafios de automação em Continuous Delivery
 
Engenharia de Testes
Engenharia de TestesEngenharia de Testes
Engenharia de Testes
 
ALM - Testes Manuais no Microsoft Test Manager
ALM - Testes Manuais no Microsoft Test ManagerALM - Testes Manuais no Microsoft Test Manager
ALM - Testes Manuais no Microsoft Test Manager
 
Aula12 T EES UFS Testes de SW
Aula12  T EES  UFS  Testes de SWAula12  T EES  UFS  Testes de SW
Aula12 T EES UFS Testes de SW
 
Aula12 TEES UFS Testes de SW
Aula12 TEES UFS Testes de SWAula12 TEES UFS Testes de SW
Aula12 TEES UFS Testes de SW
 
Apresentação testes white box
Apresentação testes white boxApresentação testes white box
Apresentação testes white box
 
Introdução à Engenharia de Testes de Software
Introdução à Engenharia de Testes de SoftwareIntrodução à Engenharia de Testes de Software
Introdução à Engenharia de Testes de Software
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
 
Eng.ª do Software - 10. Testes de software
Eng.ª do Software - 10. Testes de softwareEng.ª do Software - 10. Testes de software
Eng.ª do Software - 10. Testes de software
 
TDD com Python (Completo)
TDD com Python (Completo)TDD com Python (Completo)
TDD com Python (Completo)
 
Testes de Sistema
Testes de SistemaTestes de Sistema
Testes de Sistema
 
Introdução a tdd
Introdução a tddIntrodução a tdd
Introdução a tdd
 
Testes De Software - Uma Visão Geral
Testes De Software - Uma Visão GeralTestes De Software - Uma Visão Geral
Testes De Software - Uma Visão Geral
 
Desenvolvimento Dirigido por Testes
Desenvolvimento Dirigido por TestesDesenvolvimento Dirigido por Testes
Desenvolvimento Dirigido por Testes
 
4 engenharia de software
4   engenharia de software4   engenharia de software
4 engenharia de software
 

Fases testes

  • 1. Testes de Software Fases Baseado em notas de aula da profa. Eliane Martins
  • 2. Tópicos • Testes de Unidades • Testes de Integração • Testes de Aceitação e de Sistemas • Testes de Regressão
  • 3. Testes de Unidades Visam exercitar detalhadamente uma unidade do sistema: módulo ou função; classe ou pequenos “clusters” Aspectos a serem considerados : interfaces: verificar parâmetros de entrada e saída estruturas de dados: verificar integridade dos dados armazenados condições de limite: verificar se a unidade opera adequadamente nos limites estabelecidos tratamento de erros
  • 5. Componentes de testes-2 Necessários quando se testam unidades isoladamente. Podem ser: driver (controlador): chama a unidade em teste stub: substitui uma unidade que é chamada Casos de teste Driver Unidade em Teste Stub 1 Stub 2 resultados Stub 3
  • 6. Componentes de testes devem ser mais simples e mais rápidos de desenvolver do que as unidades substituídas grau de facilidade ou dificuldade de construí-los depende da qualidade do projeto
  • 7. Exemplo: stub type VetorInt = array [1 .. N] of integer; ... procedure Ordena_Vetor (a : VetorInt); ... begin write (“Valores fornecidos”); for i := 1 to N do write (a [ i ] ); write (“Forneça os valores ordenados”); for i := 1 to N do read (a [ i ] ); end; Módulo A Módulo Ordena_Vetor vetor desordenado vetor ordenado stub para este procedimento ?
  • 8. Exemplo - Driver Driver Módulo insereItem Módulo criaTab Módulo leItem Módulo mostraTab type TabInt = array [ 1 .. N, 1 .. M ] of integer; ... var Tabela: TabInt, x: integer; ... criaTab ; leItem ( x ); insereItem (x ); mostraTab ; ....
  • 9. Testes de integração Integram unidades já testadas critério: exercitar cada unidade pelo menos uma vez
  • 10. Falhas de integração interfaces incorretas falta, sobreposição ou conflito de funcionalidades violação da integridade de arquivos e estruturas de dados globais seqüência incorreta de unidades tratamento de erros (exceções) incorreto problema de configuração / versões falta de recursos para atender a demanda das unidades objeto incorreto é associado a mensagem (polimorfismo)
  • 11. Abordagens de integração Não incremental (“big-bang”): todas as unidades são integradas de uma só vez esforço de preparação menor esforço para diagnóstico e correção de falhas é maior Incremental as unidades são integradas gradualmente descendente (“top-down”) ascendente (“bottom-up”) por colaboração mista
  • 13. Integração ascendente (“top-down”) começa com a unidade principal e vai aos poucos integrando as unidades subordinadas em OO: classes de controle primeiro utiliza stubs em lugar das unidades subordinadas Unidade Principal Subordinada 1 Subordinada 1a Stub
  • 14. Integração ascendente (“top-down”) Pode ser feita em profundidade ou em largura interfaces de mais alto nível são testadas mais cedo Unidade Principal Subordinada 1 Subordinada 1a Stub Unidade Principal Subordinada 1 Subordinada 2 Stub em profundidade em largura
  • 15. Integração descendente (“bottom-up”) começa a integração pelas unidades subordinadas em OO: começar pelas classes independentes ou que usam poucas servidoras utiliza drivers em lugar das unidades de controle algoritmos de mais baixo nível são testados antes de serem integrados ao resto do sistema Subordinada 1a Subordinada 1b Driver1a Driver1b Subordinada 1a Subordinada 1b Unidade 1
  • 16. Integração por colaborações identifica colaborações: grupos de unidades que interagem para realizar uma ação do sistema escolhe uma colaboração integrando as unidades que a compõem critério: integrar todas as colaborações identificadas testes enfocam funcionalidades ⇒ podem ser reutilizados nos testes de sistema P1 P3 P5 P2 P4 e1 e2 e3 e4 e5 s1 s2 s3
  • 17. Integração por colaborações P3 P2 P4e4 s3 P1 P3 P5 e1 e2 e3 s1 P3 P5 P2 P4e4 e5 s2 s3 teste de 1 colaboração teste de 1 colaboração com várias entradas teste de várias colaborações
  • 18. Testes de sistemas Combinação de testes que tem por objetivo: revelar falhas de sistema demonstrar que o sistema em teste implementa os requisitos funcionais e não funcionais o sistema foi construído corretamente ?
  • 19. Fontes de informação para testes especificação de requisitos protótipo, layouts ou modelos da IU políticas da organização implementadas como objetos de negócio, “stored procedures” ou “triggers” características do produto descritas na literatura características e procedimentos descritos na documentação, telas de ajuda ou assistentes de operação (“wizards”) Especificação deve ser: • completa • consistente • precisa • testável
  • 20. Testes dos requisitos funcionais Visam verificar se as funcionalidades especificadas foram devidamente implementadas Uso de métodos de testes caixa-preta : partição de equivalência valores-limite tabela de decisão / grafo causa-efeito modelos de estado diagramas de casos de uso cenários ...
  • 21. Testes dos requisitos não funcionais Visam determinar se a implementação do sistema satisfaz aos requisitos não funcionais Tipos de testes: configuração e compatibilidade desempenho estresse tolerância a falhas segurança ...
  • 22. Testes de configuração e compatibilidade Verificam se a implementação é capaz de executar nas diferentes configurações do ambiente alvo que foram especificadas Verificam se a implementação é capaz de interoperar com sw e hw conforme especificado: sistemas já existentes plataformas específicas de hw diferentes (versões de )sistemas operacionais diferentes interfaces gráficas (X-Windows, Microsoft Windows) diferentes API e IDL diferentes SGBD
  • 23. Testes de desempenho Visam determinar se implementação satisfaz aos requisitos de desempenho especificados: configuração de rede tempo de CPU limitação de memória carga do sistema taxa de chegada de entradas esses requisitos devem ser descritos de forma testável
  • 24. Exemplo de como expressar requisitos para testes • Nro.transações/segundo • tempo de resposta • Kbytes • nro. de chips de RAM • tempo de treinamento • número de quadros de ajuda • tempo médio entre defeitos (failure) • taxa de ocorrência de defeitos • disponibilidade • tempo de reinicialização após defeito • % de eventos que levam a defeitos • probabilidade de que dados sejam corrompidos • % comandos dependentes de plataforma • número de plataformas-alvo Desempenho Tamanho Usabilidade Confiabilidade Portabilidade
  • 25. Variações dos testes de desempenho Testes de carga geralmente associados com sistemas transacionais usam simuladores de carga para geração de múltiplas transações/usuários simultâneamente Testes de volume geralmente usados para sistemas “batch” consistem na transmissão de um grande volume de informações quando o sistema está com a carga normal
  • 26. Testes de estresse Visam verificar se o sistema não apresenta um comportamento de risco quando submetido a carga elevada e com um ou mais recursos saturados Importância: muitos sistemas apresentam comportamento de risco nessa situação falhas detectadas são sutis correções desse tipo de falha podem requerer retrabalho considerável
  • 27. Testes da tolerância a falhas Visam verificar os mecanismos de detecção e recuperação de erros: recuperação automática: mecanismos implementados corretamente ? tempo de resposta é aceitável ? Recuperação manual o tempo médio de reparo é aceitável ? São realizados usando-se testes por injeção de falhas
  • 28. Testes de segurança Visam verificar a capacidade do sistema de impedir acesso não autorizado, sabotagem ou outros ataques intencionais Características básicas de segurança são testadas como as outras funcionalidades (logon/logoff, permissões) testes adicionais são geralmente feitos por especialistas ou “hackers” contratados
  • 29. Testes de validação Têm os mesmos objetivos que os testes de sistemas, só que envolvem a participação do cliente ou usuário Testes alfa: realizados por um grupo de usuários no ambiente de desenvolvimento seu objetivo é determinar se o sistema pode ser liberado Testes beta realizados por um grupo de usuários em ambiente de operação Testes de aceitação
  • 30. Testes de validação Testes de aceitação: realizados pelo cliente para decidir se aceita ou não o sistema são realizados de acordo com um plano de aceitação Testes de conformidade: visam verificar se a implementação satisfaz à legislação ou a padrões estabelecidos podem ser realizados por centros de certificação
  • 31. Testes de regressão Testes realizados a cada vez que um sw é alterado Objetivo: validar modificações feitas mostrar que modificações realizadas não afetaram as partes não modificadas isto é mostrar que o sw não regrediu
  • 32. Aplicabilidade dos testes de regressão testar aplicações críticas que devem ser retestadas freqüentemente testar sw que é alterado constantemente durante o desenvolvimento (por exemplo, Processo Incremental) testar componentes reutilizáveis para determinar se são adequados para o novo sistema durante os testes de integração durante os testes, após correções em fase de manutenção para identificar diferenças no comportamento do sistema quando há mudanças de plataforma (uso de seqüências-padrão ou “benchmarks”)
  • 33. Aplicabilidade dos testes de regressão (OO) quando uma nova subclasse é criada quando uma super-classe é alterada quando uma classe servidora é alterada quando uma classe é reusada em um novo contexto
  • 34. Abordagens para os testes de regressão Retesta tudo: reaplica todos os testes Seletiva: seleciona um subconjunto dos testes aplicados Em ambos os casos: alguns testes devem ser atualizados ou novos testes devem ser acrescentados
  • 35. Sumário Testes de integração são úteis mesmo que as unidades tenham sido testadas Abordagens de integração incremental são “mais baratas” do que abordagem não-incremental Testes de desempenho, estresse e tolerância a falhas devem ser realizados cedo na fase de testes pois podem implicar em grandes alterações (talvez de projeto) Modificações no sw são inevitáveis e introduzem falhas ⇒ testes aplicados precisam ser armazenados para uso em testes de regressão