Luiz Leão luizleao@gmail.com http://www.luizleao.com
Conteúdo Programático 4.1 Teste de Unidade 4.2 Teste de Integração 4.3 Teste de Validação 4.4 Teste de Sistema 4.5 Teste na Migração
Introdução 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.
Introdução 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.
Estratégia de Teste Os testes iniciais também conhecidos como teste de unidade focalizam um único componente e aplicam-se para descobrir erros nos dados e na lógica de processamento destes componentes. Posteriormente cada componente testado deve ser integrado. Neste momento ocorre o teste de integração, cuja preocupação é verificar problemas associados à construção do programa.
Estratégia de Teste Após esta fase ocorrem testes de ordem superior, como por exemplo, o teste de validação com o objetivo de garantir que o software satisfaz a todos os requisitos informativos, funcionais, comportamentais e de desempenho. A última etapa de teste de ordem superior é o teste de sistema que verifica se todos os elementos se combinam corretamente e se a função/desempenho global do sistema é conseguida.
Teste de Unidade
Teste de Unidade Concentra-se no estágio mais baixo da escala de teste, isto é, no código do programa e é considerado um adjunto da etapa de codificação. Normalmente é realizado pelo desenvolvedor e inicia-se depois que o código foi desenvolvido, revisado e verificado quanto à sua sintaxe. O teste de unidade baseia-se, fortemente, no teste de caixa branca.
Teste de Unidade Este tipo de teste é aplicado nos menores componentes de código criado, visando garantir que estes atendem as especificações em termos de características e de funcionalidade. O teste de unidade foca na lógica interna de processamento e nas estruturas de dados dentro dos limites de um componente, conforme a figura adiante:
Teste de Unidade
Teste de Unidade A interface de módulo é testada para assegurar que as informações fluam corretamente para dentro e para fora da unidade do programa que está sendo testada. A estrutura de dados local é examinada para garantir que os dados armazenados temporariamente mantenham sua integridade durante todos os passos na execução de um algoritmo.
Teste de Unidade A Todos os caminhos independentes da estrutura de controle são usados para assegurar que todas as instruções em um módulo tenham sido executadas pelo menos uma vez. As condições limite são testadas para garantir que o módulo opere adequadamente nas fronteiras estabelecidas para restringir ou limitar o processamento.
Teste de Unidade A Todos os caminhos de manipulação de erro são testados. Casos de testes deverão ser projetados para descobrir erros devido a computações errôneas, comparações incorretas ou fluxo de controle inadequado.
Teste de Unidade - Procedimento 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.
Teste de Unidade - Procedimento
Teste de Unidade - Procedimento 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.
Teste de Unidade - Procedimento Driver e Stub representam despesas indiretas no projeto de desenvolvimento de software, pois são softwares que devem ser escritos e que não serão fornecidos com o produto final.
Teste de Unidade - OO Quando consideramos o software orientado a objeto, o conceito de unidade se modifica. Não podemos mais testar uma única operação isoladamente como no desenvolvimento convencional, mas como parte de uma classe. Neste caso uma classe encapsulada é usualmente o foco do teste de unidade e as operações (métodos) dentro da classe são as menores unidades testáveis.
Teste de Unidade - OO Uma classe pode conter um conjunto de diferentes operações, e uma operação em particular pode existir como parte de um conjunto de diferentes classes. Assim o teste de classe para software OO é o equivalente ao teste de unidade para software convencional e foca nas operações encapsuladas na classe e pelo estado de comportamento da classe.
Teste de Integração
Teste de Integraçã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 a Mesmo que todos os módulos estejam funcionando individualmente, 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 A 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 Validação
Teste de Sistema
Teste de Sistema O objetivo do teste de sistema é realizar a execução do sistema como um todo, dentro de um ambiente operacional controlado, para validar a exatidão e perfeição na execução de suas funções, acompanhando cenários sistêmicos elaborados pelo profissional de requisitos do projeto e devem retratar os requisitos funcionais e não-funcionais do sistema.
Teste de Sistema Normalmente este tipo de teste é realizado por uma equipe de teste independente, onde o analista de teste irá elaborar os casos de testes, normalmente em conjunto com os desenvolvedores e executando os testes em um ambiente controlado, no caso o ambiente de teste.
Teste na Migração
Teste na Migração Necessidade da adequada sintonia entre os dados armazenados no sistema anterior e os dados sob novo formato, com tecnologia moderna, tratados pelo novo sistema; Deve haver a verificação dos procedimentos operacionais e legais para a migração Preparação prévia da migração, com simulação e verificação dos procedimentos operacionais, financeiros e legais usados no sistema antigo e seu rebatimento no novo sistema, sempre com a concordância do usuário gestor, face a questão básica da manutenção do negócio, ou seja, mudar para melhor dentro dos requisitos de negócio estabelecido;
Validação do novo formato de banco de dados Este deve possibilitar a migração de dados do antigo sistema. Os campos de dados no sistema novo que não existem no banco de dados antigo, deve ter estratégia de povoamento;
Teste de migração dos dados do banco de dados Simular a migração do acervo de dados, aplicando os necessários testes de validação entre os dados originados no Software Gerenciador de Banco de Dados (SGBD) do sistema antigo e os novos dados armazenados no novo SGBD do novo sistema; Simulação do novo sistema em substituição ao sistema antigo - em paralelo ao antigo sistema, Simular o novo sistema em condições reais de funcionamento para que o usuário gestor possa avaliar possíveis necessidades de ajustes do fluxo operacional e computacional de forma a trazer benefícios com a instalação do novo sistema.