Teste de Software Aula 7

Prévia do material em texto

TESTES DE SOFTWARE – AULA 7 
Prof. Ulisses Sperle Graça
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;
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
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.
5
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;
6
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.
7
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?
8
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á!
9
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.
10
QUEM REALIZA O TESTE?
Existem várias responsabilidades e papéis dentro da equipe:
11
QUEM REALIZA O TESTE?
Líder do projeto
de testes
Responsável pela liderança de um projeto de teste,
geralmente relacionado a um sistema em desenvolvi-
mento, seja um projeto novo ou manutenção.
Arquiteto Responsável pela montagem da infraestrutura de teste,
monta o ambiente de teste, escolhe as ferramentas de
teste e capacita a equipe para executar seu trabalho
neste ambiente.
Analista
do teste
Responsável pela modelagem e elaboração dos casos
de teste e pelos scripts de teste. Em alguns casos, os
scripts podem ser elaborados pelos testadores.
Testador Responsável pela execução dos casos de teste e
scripts.
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.
12
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.
13
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.
14
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.
15
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.
16
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.
17
PORQUE É IMPORTANTE?
Pessoal:
 Usuários;
 Desenvolvedores;
 Testadores.
Hardware:
 Plataforma;
 Impressoras;
 Scanners;
18
AMBIENTE DE TESTE
Software:
 Software a ser testado;
 Sistema operacional;
 Software de teste, procedimentos.
Suprimentos:
 Papel;
 Formulários;
 Cartuchos de Tinta.
19
AMBIENTE DE TESTE
Rede:
 Protocolos;
 Autorizações;
 Usuários.
Documentação:
 Requisitos;
 Design;
 Cartuchos de Tinta.
20
AMBIENTE DE TESTE
Ambiente físico:
 Local;
 Segurança;
 Estrutura.
21
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.
22
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;
23
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.
24
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.
25
VERIFICAÇÃO & VALIDAÇÃO
Segundo Boehm:
 Verificação – “Estamos construindo certo o produto?”
 Validação – “Estamos construindo o produto certo?”
26
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.
27
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.
28
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.
29
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.
30
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.
31
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.
32
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.
33
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:
34
TESTE DE UNIDADE
35
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.
36
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.
37
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.
38
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.
39
TESTE DE UNIDADE - PROCEDIMENTO
40
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.
41
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.
42
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.
43
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.
44
TESTE DE UNIDADE - OO