Estratégia de Teste de Software

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

*
TESTES DE SOFTWARE – AULA 5
Prof. Ulisses Sperle Graça
Rio de Janeiro, setembro de 2011
ESTRATÉGIA DE 
TESTE DE SOFTWARE
TESTE DE UNIDADE
*
1. Compreender e definir os testes de interior do programa;
2. Implementar testes para o interior do programa;
3. Compreender técnicas de teste de integração de módulos do sistema;
4. Definir estratégia de testes para integração de módulos do 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. 
*
INTRODUÇÃO
*
Compreenderemos as principais estratégias de teste de software de forma a promover uma abordagem de teste personalizada e de diferentes níveis de forma a atingir todas as fases do ciclo de desenvolvimento do software. 
 
Discutiremos a relevância da utilização de uma equipe independente de teste no processo de teste de software, a importância da criação do ambiente de teste e a aplicação de teste unitário pelo desenvolvedor.
*
INTRODUÇÃO
*
Integra técnicas de projeto de casos de teste numa série bem definida de passos;
Proporciona um mapa que descreve os passos a serem dados como parte da atividade de teste;
Deve incorporar planejamento de teste, projeto de casos de teste, execução de testes e a resultante coleta e avaliação;
*
ESTRATÉGIA DE TESTE DE SOFTWARE
*
Deve ser flexível o bastante para promover a criatividade e a customização necessárias para testar adequadamente;
Deve ser rígida o bastante para promover um razoável planejamento e rastreamento. 
*
ESTRATÉGIA DE TESTE DE SOFTWARE
*
Aqui nós precisamos responder as seguintes perguntas:
Como conduzir os testes de software?
Devemos estabelecer um plano formal para os testes?
Devemos testar o programa como um todo ou executar testes somente em uma parte dele?
Devemos refazer os testes quando acrescentamos novos componentes ao sistema?
Quando devemos envolver o cliente?
*
ESTRATÉGIA DE TESTE DE SOFTWARE
*
Do ponto de vista psicológico, as atividades de análise e projeto, junto com a programação, são tarefas construtivas.
Por outro lado, a atividade de teste pode ser vista, psicologicamente, como uma tarefa destrutiva.
Por esse motivo, é comum o desenvolvedor “pisar leve”, projetando e executando testes que demonstrem que o sistema funciona, em vez de descobrir erros.
Se o Engenheiro de Software não o encontrar, o cliente o fará!
*
QUEM REALIZA O TESTE?
*
Normalmente para que o processo de teste transcorra de forma íntegra é comum a utilização de um grupo independente de teste, já que as pessoas que criaram o software não devem ser as que irão realizar os testes. Seria um conflito de interesses pois foram elas que o “criaram”.
Este grupo trabalha de forma conjunta e existem testes que somente serão conduzidos pelos desenvolvedores, como o teste de unidade que iremos estudar mais adiante. 
*
QUEM REALIZA O TESTE?
*
Existem várias responsabilidades e papéis dentro da equipe:
*
QUEM REALIZA O TESTE?
Fonte: Rios.E & Moreira,T. Testes de Software. Rio de Janeiro. Alta Books, 2003
*
Interpretações Erradas:
1 - De modo algum o desenvolvedor deve testar.
	 ele é sempre responsável por testar as unidades individuais (componentes) do programa. Em muitos casos também realiza o teste de integração (teste da estrutura completa do programa). Só depois é que um Grupo Independente de Teste se envolve.
*
QUEM REALIZA O TESTE?
*
Interpretações Erradas (cont.):
2 - O software deve ser “jogado” aos “estranhos” do ITG.
	 os dois grupos trabalham estreitamente unidos ao longo do projeto de software. O desenvolvedor deve também estar à disposição para corrigir erros que sejam descobertos.
*
QUEM REALIZA O TESTE?
*
Interpretações Erradas (cont.):
3 - O ITG se envolverá com o projeto somente quando o teste começar.
  O ITG faz parte da equipe de desenvolvimento de software, ou seja, se torna envolvido a partir do processo de especificação ao longo de um grande projeto.
*
QUEM REALIZA O TESTE?
*
O papel do ITG é remover os problemas inerentes ao fato de deixar que o construtor teste o que foi construído, de forma a suprimir o conflito de interesses.
Em muitos casos o ITG pertence ao grupo de GQS, conseguindo assim um grau de independência maior.
*
QUEM REALIZA O TESTE?
*
Muitas vezes o teste requer mais trabalho de projeto do que qualquer outra ação da engenharia de software.
Consequentemente caso seja feito casualmente, erros podem passar sem ser detectados.
 Lembra do teste de software para ambientes críticos? (ex.: controle de voo, monitoramento de reatores nucleares, etc.) ele pode custar de três a cinco vezes mais do que todos os outros passos de engenharia de software combinados.
*
PORQUE É IMPORTANTE?
*
A especificação do teste documenta a abordagem da equipe de software para o teste, que descreve uma estratégia global e um procedimento designando etapas específicas de teste e os tipos de testes que serão feitos.
Após a definição da estratégia de testes é necessário criar o ambiente de teste, que não é apenas uma configuração de hardware, mas toda uma estrutura a ser considerada onde o teste será executado.
*
PORQUE É IMPORTANTE?
*
Pessoal:
 Usuários;
 Desenvolvedores;
 Testadores.
Hardware:
Plataforma;
Impressoras;
Scanners;
*
AMBIENTE DE TESTE
*
Software:
 Software a ser testado;
 Sistema operacional;
 Software de teste, procedimentos.
Suprimentos:
Papel;
Formulários;
Cartuchos de Tinta.
*
AMBIENTE DE TESTE
*
Rede:
 Protocolos;
 Autorizações;
 Usuários.
Documentação:
Requisitos;
Design;
Cartuchos de Tinta.
*
AMBIENTE DE TESTE
*
Ambiente físico:
 Local;
 Segurança;
 Estrutura.
*
AMBIENTE DE TESTE
*
Lembre-se:
Teste é um conjunto de atividades que pode ser planejado antecipadamente e realizado sistematicamente.
Por essa razão, um gabarito de testes de software deve ser definido para o processo de software.
Um gabarito de testes é um conjunto de passos no qual podemos incluir técnicas de projeto de casos de teste e métodos de teste específicos.
*
ABORDAGEM ESTRATÉGICA
*
Características genéricas de uma estratégia de Teste :
 Para realizar um teste efetivo, uma equipe de software deve conduzir as RTF, quando muitos erros serão eliminados antes do início do teste;
 O teste inicia-se no nível de componente e prossegue “para fora”, na direção da integração de todo o sistema;
 Diferentes técnicas de teste são apropriadas a diferentes situações ou momentos;
*
ABORDAGEM ESTRATÉGICA
*
Características genéricas de uma estratégia de Teste :
 A atividade de teste pode ser realizada pela própria equipe de desenvolvedores ou por um grupo de teste independente;
 As atividades de Teste e de Depuração são diferentes, mas a depuração deve ser acomodada em qualquer teste. 
*
ABORDAGEM ESTRATÉGICA
*
A atividade de teste de software é uma parte de um tema mais amplo que é chamado de Verificação e Validação.
Verificação  conjunto de atividades que garante que o software implemente corretamente uma função específica.
Validação  conjunto de atividades que garante que o software que foi construído é adequado às exigências do cliente.
*
VERIFICAÇÃO & VALIDAÇÃO
*
Segundo Boehm:
 
Verificação – “Estamos construindo certo o produto?”
Validação – “Estamos construindo o produto certo?”
*
VERIFICAÇÃO & VALIDAÇÃO
*
A definição de V&V abrange muitas das atividades discutidas na Garantia da Qualidade de Software.
Os métodos de Engenharia de Software proporcionam a base a partir da qual a qualidade é conseguida.
A atividade de teste
constitui o último reduto, no qual a qualidade do software pode ser avaliada e erros podem e devem ser descobertos.
*
VERIFICAÇÃO & VALIDAÇÃO
*
“Não se pode testar a qualidade. Se ela não estiver lá antes de você começar a testar, não estará lá quando você tiver terminado de testar.” (Pressman).
A qualidade é incorporada ao software em todo o processo de engenharia de software.
A aplicação adequada de métodos e ferramentas, RTFs e um gerenciamento e medição sólidos, todos levam à qualidade que é confirmada durante o teste.
*
VERIFICAÇÃO & VALIDAÇÃ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.
*
UMA ESTRATÉGIA DE TESTE
*
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.
*
UMA 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.
*
UMA 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.
*
UMA ESTRATÉGIA DE TESTE
*
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 especi-ficaçõ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 compo-nente, 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
*
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
*
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
*
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 - PROCEDIMENTO
*
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 UNIDADE - OO
*