Aula_06

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

*
TESTES DE SOFTWARE – AULA 6
Prof. Ulisses Sperle Graça
Rio de Janeiro, setembro de 2011
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.
*
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. 
*
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.
*
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.
*
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.
*
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.
*
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.
*
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;
*
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.
*
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.
*
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:
*
TESTE DE INTEGRAÇÃO
*
Integração descendente ou Top-down;
Integração ascendente ou Botton-up;
Teste de regressão;
Teste fumaça.
*
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:
*
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.
*
TESTE DE INTEGRAÇÃO - Incremental
*
Integração Descendente ou Top-down
	Primeiro-em-profundidade (depth-first)
*
TESTE DE INTEGRAÇÃO - Incremental
*
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. 
*
TESTE DE INTEGRAÇÃO - Incremental
*
Integração Descendente ou Top-down
	Primeiro-em-largura (breadth-first)
*
TESTE DE INTEGRAÇÃO - Incremental
*
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.
*
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.
*
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. 
*
LEMBRANDO: DRIVER E STUB
*
O processo de integração funciona em uma série de cinco passos:
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.
Dependo da abordagem de integração selecionada os pseudocontrolados são substituídos, um de cada vez, pelos componentes reais.
*
TESTE DE INTEGRAÇÃO – TOP-DOWN
*
O processo de integração funciona em uma série de cinco passos (cont.):
Os testes são conduzidos à medida que cada componen-te é integrado.
 Ao término de cada conjunto de testes, outro pseudocon-trolado é substituído pelo componente real.
O teste de regressão pode ser conduzido para garantir que novos erros não tenham sido introduzidos.
*
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 resolver este 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.
*
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. 
*
TESTE DE INTEGRAÇÃO - Incremental
*
O processo de integração funciona em uma série de quatro passos:
Componentes de baixo nível são combinados em agregados (clusters), que realizam uma subfunção específica.
Um pseudocontrolador é escrito para coordenar a entrada e a saída do caso de teste.
*
TESTE DE INTEGRAÇÃO – BOTTON-UP
*
O processo de integração funciona em uma série de quatro passos (cont.):
O agregado é testado.
Pseudocontroladores são removidos e agregados são combinados movendo-se para cima na estrutura.
*
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. 
*
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.
*
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.
*
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.
*
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. 
*
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.
*
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:
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.
*
TESTE FUMAÇA
*
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.
A construção é integrada com outras construções e o produto inteiro é testado diariamente. A abordagem pode ser descendente ou ascendente.
*
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. 
*
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.
*
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;
*
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.
*
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.
*
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:
*
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.
*
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.
*
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.
*
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:
 
Teste baseado no caminho de execução: Integra o conjunto de classes necessárias para responder a uma entrada ou evento do sistema.
*
TESTE DE INTEGRAÇÃO - OO
*
Teste baseado no uso: Começa a construção do sistema testando as classes que usam poucas (ou nenhuma) classes servidoras.
*
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.
*
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.
*
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.
*
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:
*
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.
*
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;
*
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.
*
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. 
*
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.
*
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. 
*
TESTE DE VALIDAÇÃO
*