Teste de Software Aulas 8 E 9

Prévia do material em texto

TESTES DE SOFTWARE – AULAS 8 E 9
Prof. Ulisses Sperle Graça
ESTRATÉGIA DE 
TESTE DE SOFTWARE
TESTE DE INTEGRAÇÃO
E
TESTE DE VALIDAÇÃO
1. Compreender técnicas de teste de integração de módulos 
do sistema;
2. Definir estratégia de testes para integração de módulos 
do sistema;
3. Compreender técnicas de teste de validação de sistema;
4. Definir estratégia de teste de validação de sistema.
3
OBJETIVOS DESTA AULA
O software é testado para revelar erros cometidos
inadvertidamente quando projetado é construído.
Neste sentido torna-se necessária a definição de uma
estratégia de teste de software de forma a orientar os
desenvolvedores e as equipes independentes de testes, os
passos a serem seguidos, o tempo de trabalho e os
recursos necessários.
4
LEMBRANDO
“O processo de desenvolvimento de sistemas pode ser
visto como uma espiral com suas etapas movimentando-se
para dentro enquanto que a estratégia de teste pode ser
vista movimentando-se para fora.
5
LEMBRANDO
Considerando de um ponto de vista procedimental, o teste
no contexto da Engenharia de Software é uma série de
quatro passos, que são implementados sequencialmente.
6
LEMBRANDO
Enquanto o teste de unidade focaliza cada componente
individualmente, garantindo que ele funcione adequada-
mente como uma unidade, o teste de integração cuida de
problemas associados com aspectos duais de verificação e
construção do programa.
Visa, a partir dos módulos testados no nível de unidade,
construir a estrutura de programa que foi determinado pelo
projeto, ou seja, tem por objetivo testar, de forma integrada,
os módulos do sistema.
7
INTRODUÇÃO
Depois da integração, são executados os de testes de ordem
superior. Os critérios de validação estabelecidos durante a
análise de requisitos devem ser avaliados.
O teste de validação irá proporcionar a garantia final de que
o software satisfaz a todos os requisitos informativos,
funcionais, comportamentais e de desempenho.
8
INTRODUÇÃO
O teste de integração focaliza o pacote de software completo
e trata da verificação do programa como um todo. Este tipo
de teste faz uso de técnicas de projeto de casos de teste que
enfocam as entradas e saídas, além de exercitar caminhos
específicos.
9
TESTE DE INTEGRAÇÃO
Mesmo que todos os módulos estejam funcionando indivi-
dualmente, não se pode garantir que eles funcionarão em
conjunto:
 Os dados podem ser perdidos na interface;
 A imprecisão aceitável individualmente de cada módulo
pode ser amplificada no funcionamento em conjunto;
 As estruturas de dados globais podem apresentar
problemas;
10
TESTE DE INTEGRAÇÃO
Segundo Pressman, o teste de integração é uma técnica
sistemática para construir a arquitetura do software enquanto
se conduz testes para descobrir erros associados com as
interfaces a partir dos componentes já testados através do
teste de unidade. Existem basicamente duas abordagens
que podem ser utilizadas:
 Não incremental;
 Incremental.
11
TESTE DE INTEGRAÇÃO
Não incremental (Big-Bang):
Nesta abordagem todos os componentes são combinados
com antecedência e o programa inteiro é testado de uma
vez. Segundo Pressman, usualmente, o resultado desta
abordagem é o caos, pois normalmente são encontrados
muitos erros tornando a correção difícil, pois fica complicado
isolar as causas dos erros. Uma vez corrigidos os erros,
novos erros aparecem e o processo parece não ter fim.
12
TESTE DE INTEGRAÇÃO
Incremental
Abordagem que é a antítese da abordagem big-bang. O
programa é construído e testado em pequenos incrementos.
Os erros são mais fáceis de isolar e corrigir e pode ser
aplicada uma interface sistemática de testes. Neste contexto
existem várias estratégias incrementais de integração:
13
TESTE DE INTEGRAÇÃO
 Integração descendente ou Top-down;
 Integração ascendente ou Botton-up;
 Teste de regressão;
 Teste fumaça.
14
TESTE DE INTEGRAÇÃO - Incremental
Integração Descendente ou Top-down
Os módulos são integrados movendo-se de cima para 
baixo na hierarquia de controle. Começa-se pelo módulo de 
controle principal e os módulos subordinados são 
incorporados à estrutura de uma de duas maneiras:
15
TESTE DE INTEGRAÇÃO - Incremental
Integração Descendente ou Top-down
Primeiramente pela profundidade (Depth-first):
 integra os módulos de forma vertical; 
Primeiramente pela largura (Dreadth-first):
 integra os módulos de forma horizontal.
16
TESTE DE INTEGRAÇÃO - Incremental
Integração Descendente ou Top-down
Primeiro-em-profundidade (depth-first)
17
TESTE DE INTEGRAÇÃO - Incremental
M 1
M 3M 2 M 4
M 7M 6M 5
M 8
Integração Descendente ou Top-down
Primeiro-em-profundidade (depth-first): Integra todos os
componentes em um caminho de controle principal da
estrutura do controle. A seleção do caminho é arbitrária. Por
exemplo, poderíamos escolher o caminho da esquerda e
neste caso, os componentes M1, M2 e M5 seriam integrados
primeiro, posteriormente M8 ou (se necessário para o
adequado funcionamento de M2 ) M6 seria integrado.
18
TESTE DE INTEGRAÇÃO - Incremental
Integração Descendente ou Top-down
Primeiro-em-largura (breadth-first)
19
TESTE DE INTEGRAÇÃO - Incremental
M 1
M 3M 2 M 4
M 7M 6M 5
M 8
Integração Descendente ou Top-down
Primeiro-em-largura (breadth-first): Incorpora todos os
componentes diretamente subordinados em cada nível,
movendo-se através da estrutura horizontalmente. Neste
caso, no exemplo abaixo os módulos M2, M3 e M4 seriam
integrados primeiro e em seguida o próximo nível de controle
M5, M6 e M7. Por último seria integrado o módulo M8.
20
TESTE DE INTEGRAÇÃO - Incremental
Uma vez que um componente pode não ser um programa
individual, softwares driver e/ou stub podem ser
necessários para a realização do teste.
Driver (pseudocontrolador) é um substituto temporário de
um módulo superior que permite que um módulo
subordinado a ele seja testado.
Stub (pseudocontrolado) é um substituto temporário de um
módulo subordinado que permite que o módulo ao qual está
subordinado seja testado.
21
LEMBRANDO: DRIVER E STUB
Um driver representa o “programa principal” que aceita
dados do caso de teste e passa esses dados para o
componente a ser testado.
Um stub utiliza a interface dos módulos subordinados, pode
fazer uma manipulação de dados mínima através de
verificação de entrada e retorno do controle para o módulo
que está sendo testado.
22
LEMBRANDO: DRIVER E STUB
O processo de integração funciona em uma série de cinco
passos:
1. O módulo de controle principal é usado como
pseudocontrolador do teste e pseudocontrolados são
substituídos por todos os componentes diretamente
subordinados ao módulo de controle principal.
2. Dependo da abordagem de integração selecionada os
pseudocontrolados são substituídos, um de cada vez,
pelos componentes reais.
23
TESTE DE INTEGRAÇÃO – TOP-DOWN
O processo de integração funciona em uma série de cinco
passos (cont.):
3. Os testes são conduzidos à medida que cada componen-
te é integrado.
4. Ao término de cada conjunto de testes, outro pseudocon-
trolado é substituído pelo componente real.
5. O teste de regressão pode ser conduzido para garantir
que novos erros não tenham sido introduzidos.
24
TESTE DE INTEGRAÇÃO – TOP-DOWN
Desvantagem
O processamento nos níveis baixos da hierarquia pode ser
necessário para testar adequadamente os níveis superiores,
porém como são usados pseudocontrolados, nenhum dado
significativo flui para cima na estrutura do programa. Para
resolvereste tipo de questão três soluções são possíveis:
 Adiar alguns testes;
 Desenvolver pseudocontrolados mais complexos;
 Integrar o software de baixo para cima.
25
TESTE DE INTEGRAÇÃO – TOP-DOWN
Integração Ascendente ou Botton-up
A integração do sistema começa a partir do nível mais baixo 
do software, ou seja, o módulo. O módulo é dito como o mais 
baixo nível se ele não depende de outro módulo. Neste tipo 
de teste assume-se que previamente todos os módulos 
foram individualmente testados. Os módulos são integrados 
movendo-se de baixo para cima na hierarquia de controle. 
26
TESTE DE INTEGRAÇÃO - Incremental
O processo de integração funciona em uma série de quatro
passos:
1. Componentes de baixo nível são combinados em
agregados (clusters), que realizam uma subfunção
específica.
2. Um pseudocontrolador é escrito para coordenar a entrada
e a saída do caso de teste.
27
TESTE DE INTEGRAÇÃO – BOTTON-UP
O processo de integração funciona em uma série de quatro
passos (cont.):
3. O agregado é testado.
4. Pseudocontroladores são removidos e agregados são 
combinados movendo-se para cima na estrutura.
28
TESTE DE INTEGRAÇÃO – BOTTON-UP
Nesta abordagem, os componentes são combinados para
formar os agregados (clusters) 1, 2 e 3, conforme o desenho.
Cada um dos agregados é testado usando um driver, que é
demonstrado com linhas tracejadas.
29
TESTE DE INTEGRAÇÃO – BOTTON-UP
3
Neste exemplo os agregados 1 e 2 são subordinados a Ma.
Após os testes dos agregados 1 e 2 os pseudocontroladores
D1 e D2 são removidos e os agregados interfaceados
diretamente com Ma. Os testes continuam e os drivers são
removidos a cada integração. A medida que a integração se
move para cima a necessidade de drivers de testes
separados diminui.
30
TESTE DE INTEGRAÇÃO – BOTTON-UP
São executados após a correção de algum defeito ou após a
adição de uma nova funcionalidade. Seu objetivo é garantir
que nenhum defeito foi acrescentado após sua modificação.
Toda vez que um novo módulo é adicionado como parte do
teste de integração, o software se modifica e assim novos
caminhos de fluxos de dados são estabelecidos, nova E/S
pode ocorrer ou ainda nova lógica de controle pode ser
adicionadas. Essas modificações podem causar problemas
em funções que previamente funcionavam corretamente.
31
TESTE DE REGRESSÃO
Os casos de testes de regressão podem ser de três tipos:
 Casos de teste que abrangem todas as
funcionalidades do sistema.
 Casos de teste apenas para as funcionalidades que
foram modificadas.
 Novos casos de teste para as funcionalidades que
provavelmente foram afetadas pela mudança.
32
TESTE DE REGRESSÃO
O teste de regressão é a reexecução de algum subconjunto
de testes que já foi conduzido para garantir que as
modificações não introduzam efeitos colaterais indesejáveis.
Ele pode ser conduzido manualmente ou usando alguma
ferramenta automatizada de captação/reexecução e que
iremos estudar posteriormente.
33
TESTE DE REGRESSÃO
A utilização de ferramentas automatizadas irão permitir ao
engenheiro de software captar casos de teste e resultados
para reexecução e comparação, pois à medida que o teste
de integração prossegue, o número de testes de regressão
pode crescer significativamente.
Assim a suíte de testes de integração deve ser projetada
para incluir apenas testes que cuidam das principais funções
do programa.
34
TESTE DE REGRESSÃO
É projetado como mecanismo de marca-passo para projetos
de prazo crítico, permitindo que a equipe avalie seu projeto
frequentemente. De uma forma geral, esta abordagem
abrange as seguintes atividades:
1. Os componentes de software são integrados em uma
“construção”. Esta construção inclui todos os dados,
bibliotecas, módulos reusáveis e componentes que são
necessários para implementar uma ou mais funções do
produto.
35
TESTE FUMAÇA
2. Uma série de testes é projetada para expor erros que
impeçam a construção de desempenhar adequadamente
a sua função. A finalidade deverá ser descobrir erros
“bloqueadores” que tem a maior chance de atrasar o
cronograma.
3. A construção é integrada com outras construções e o
produto inteiro é testado diariamente. A abordagem pode
ser descendente ou ascendente.
36
TESTE FUMAÇA
 O risco de integração é minimizado já que
incompatibilidades e outros erros de bloqueio são
descobertos logo no início, evitando impactos no
cronograma.
 A qualidade do produto final é aperfeiçoada, pois tanto
erros funcionais quanto defeitos de projeto arquitetural
podem ser descobertos.
37
TESTE FUMAÇA - BENEFÍCIOS
 Diagnóstico e correção de erros são simplificados, pois o
software que acabou de ser adicionado às construções é
uma causa provável do erro recém-descoberto.
 O progresso é fácil de avaliar, pois como a cada dia que
passa, o teste está mais integrado ao software,
demonstrando como ele funciona.
38
TESTE FUMAÇA - BENEFÍCIOS
Qual o melhor top-down ou botton-up?
A maior desvantagem da abordagem top-down é a
necessidade de ter stubs e as dificuldades de testes
resultantes, por outro lado o stub possibilita testar logo as
principais funções de controle;
A maior desvantagem da integração botton-up é que o
programa não existe como entidade até que o último módulo
seja adicionado, que por outro lado nos traz a vantagem de
testes mais fáceis pela ausência do stub;
39
TESTE DE INTEGRAÇÃO - CONCLUSÃO
Uma abordagem combinada, denominada teste sanduíche,
que usa top-down para os módulos de níveis superiores e
botton-up para os níveis subordinados pode ser a melhor
opção;
A escolha depende das características do software.
40
TESTE DE INTEGRAÇÃO - CONCLUSÃO
O documento de especificação de teste é um produto de 
trabalho e torna-se parte da configuração de software. Ele 
especifica os seguintes documentos: 
 Plano de teste global para integração do software;
 Descrição dos testes específicos.
41
TESTE DE INTEGRAÇÃO - DOCUMENTAÇÃO
O plano de teste descreve a estratégia global da integração.
O teste é dividido em fases e construções que tratam de
características funcionais e comportamentais específicas do
software e está relacionada a um domínio específico dentro
da arquitetura do software.
Os seguintes critérios e testes correspondentes são
aplicados a todas as fases de teste:
42
TESTE DE INTEGRAÇÃO - DOCUMENTAÇÃO
Integridade da interface: as interfaces interna e externa
são testadas à medida que cada módulo é incorporado a
estrutura.
Validade funcional: São projetados testes destinados a
descobrir erros funcionais.
43
TESTE DE INTEGRAÇÃO - DOCUMENTAÇÃO
Conteúdo de informação: São projetados testes para
descobrir erros associados com estruturais de dados globais
ou locais.
Desempenho: São projetados testes destinados a verificar
os limites de desempenho estabelecidos durante o projeto do
software.
44
TESTE DE INTEGRAÇÃO - DOCUMENTAÇÃO
O plano de teste deve conter:
Um cronograma para a integração;
Breve descrição do software de uso geral (drivers e stubs);
Descrição do ambiente e recursos do teste;
Procedimento detalhado de teste que é necessário para 
realizar o plano de teste;
A ordem de integração e os testes correspondentes em cada 
etapa de integração;
Lista de todos os casos de testes e os resultados esperados.
45
TESTE DE INTEGRAÇÃO - DOCUMENTAÇÃO
Como o software orientado à objetos não tem uma estrutura
óbvia de controle hierárquico, as estratégias de integração
ascendente e descendente perdem o significado, porém há
duas estratégias existentes para o contexto OO:1. Teste baseado no caminho de execução: Integra o
conjunto de classes necessárias para responder a uma
entrada ou evento do sistema.
46
TESTE DE INTEGRAÇÃO - OO
2. Teste baseado no uso: Começa a construção do
sistema testando as classes que usam poucas (ou
nenhuma) classes servidoras.
47
TESTE DE INTEGRAÇÃO - OO
O uso de drivers e stubs também muda quando é
executado o teste de integração de sistemas OO:
Drivers podem ser usados para testar operações no mais
baixo nível e testar grupos inteiros de classes, e para
substituir a interface com o usuário.
Stubs podem ser usados em situações nas quais a
colaboração entre classes é necessária.
48
TESTE DE INTEGRAÇÃO - OO
O teste de validação começa quando termina o teste de
integração, quando o software está complementarmente
montado como um pacote e os erros de interface já foram
descobertos e corrigidos.
Neste tipo de teste a distinção entre software convencional e
software orientado a objeto desaparece. Ele focaliza ações
visíveis ao usuário e saídas do sistema reconhecíveis pelo
usuário, o foco está no nível de requisitos.
49
TESTE DE VALIDAÇÃO
Validação pode ser definida de vários modos, mas uma
definição simples, mas rigorosa, é que ela se torna bem
sucedida quando o software funciona de um modo que pode
ser razoavelmente esperado pelo cliente.
Expectativas razoáveis são definidas nas Especificações
dos Requisitos do Software – um documento que descreve
todos os atributos do software visíveis ao usuário.
A especificação contém uma seção chamada de Critérios de
Validação, que serve como base para o teste de Validação.
50
TESTE DE VALIDAÇÃO
Critérios do teste de validação
A validação de software é conseguida através de uma série
de testes que demonstram conformidade com os requisitos.
Desta forma o plano de teste descreve as classes de testes
a serem conduzidas e um procedimento de teste define
casos de teste específicos destinados a:
51
TESTE DE VALIDAÇÃO
 garantir que todos os requisitos funcionais sejam
satisfeitos;
 todas as características comportamentais seja obtidas;
 Todo o conteúdo seja preciso e adequadamente
apresentado;
 todos os requisitos de desempenham sejam atendidos;
 a documentação esteja correta.
52
TESTE DE VALIDAÇÃO
Após cada caso de teste de validação ter sido conduzido,
existe uma entre duas possibilidades:
 A característica de função ou desempenho está de
acordo com a especificação e é aceita;
 Descobre-se um desvio da especificação e é criada
uma lista de deficiência;
53
TESTE DE VALIDAÇÃO
É muito difícil para um desenvolvedor prever como cliente
usará realmente o programa. As instruções podem ser mal
interpretadas, combinações estranhas de dados, saída que
parecia clara pode ser ininteligível para um usuário e etc.
Se o software é desenvolvido para ser usado por vários
clientes, não é pratico realizar testes formais de aceitação
com cada um. A maioria dos construtores usa os processos
chamados de testes alfa e beta.
54
TESTE DE VALIDAÇÃO
Teste Alfa
Este teste é conduzido na instalação do desenvolvedor por
um grupo representativo de usuários finais.
O software é utilizado em um cenário natural e realizado em
conjunto desenvolvedores e usuários, registrando os erros e
os problemas de uso.
Este tipo de teste normalmente é conduzido em um ambiente
controlado.
55
TESTE DE VALIDAÇÃO
Teste Beta
É conduzido nas instalações de um ou mais usuários finais e
neste tipo de teste o desenvolvedor não estará presente.
O cliente registra todos os problemas encontrados durante o
teste e vai relatando para o desenvolvedor em intervalos
regulares.
Com o resultado deste teste, os desenvolvedores fazem as
modificações necessárias e preparam a liberação do
software para todos os clientes.
56
TESTE DE VALIDAÇÃO
Teste Beta (cont.)
Existem muitas empresas que colocam versões beta de seus
softwares na internet para que os usuários possam fazer o
teste com o novo produto que neste caso, ainda não foi
lançado oficialmente.
57
TESTE DE VALIDAÇÃO