Aula 9

Prévia do material em texto

Teste de Sistema
Verificação e Validação de Software, UASC/UFCG, 
Profa Patrícia D. L. Machado / Prof. Everton L. G. Alves
Introdução
• Teste de Sistema:
▫ Procura detectar bugs por meio da utilização do sistema, 
como se fosse um usuário final
▫ Verifica se o produto satisfaz seus requisitos
• Pressuposto:
▫ Testes de unidade e de integração 
já foram realizados
Objetivos
Aceitação
Instalação
Teste Alpha e Beta
Confiabilidade
Regressão
Performance
Segurança (safety)
Proteção (security)
Stress
Back-to-Back
Recuperação
Interface
Conformidade 
Usabilidade
Smoke Testing
Quantidade mínima de testes que podem ser executados para garantir que o SUT 
está pronto para testes mais elaborados.
Pode ser executado por um testador experiente que “brinca” com o software para 
observar se funcionalidades básicas estão sendo atendidas.
Teste de Aceitação
Qualquer tipo de teste que garanta que o SUT atende a seus requisitos de forma 
aceitável o processo de desenvolvimento possa avançar para outras fases, tais 
como, testes, entrega, preparação para entrega, etc.
Alguns tipos:
● Operational/field testing
● User acceptance testing
● Alpha/Beta testing
Teste Exploratório
Teste sem um plano específico que envolve aprendizado, design de casos de 
teste e execução de forma simultânea.
Busca descobrir como o software realmente funciona e fazer perguntas sobre 
como ele lidará com casos difíceis e fáceis.
O testador aprende sobre o SUT e juntamente com a experiência e a criatividade, 
gera novos testes para serem executados.
Abordagem pode ser aplicada a qualquer técnica de teste,
 em qualquer estágio do processo de desenvolvimento. 
O ponto chave é o engajamento do testador.
Exploratório versus “Baseado em Script”
No teste baseado em script, os casos 
de teste são planejados com 
antecedência. Isso inclui as etapas 
individuais e os resultados 
esperados. 
Casos de teste são executados 
posteriormente por um testador que 
compara o resultado real com o 
esperado. 
No exploratório, as expectativas 
estão abertas. Alguns resultados 
podem ser previstos e esperados; 
outros não podem. 
O testador configura, opera, observa 
e avalia o produto e seu 
comportamento, investigando 
criticamente o resultado e relatando 
informações que parecem ser um 
bug ou um problema.
https://en.wikipedia.org/wiki/Exploratory_testing
Teste Exploratório: Vantagens e Desvantagens
Flexibilidade para conduzir os testes 
e explorar o SUT
Descobrir defeitos não previstos
"Programs that pass certain tests 
tend to continue to pass the same 
tests and are more likely to fail other 
tests or scenarios that are yet to be 
explored."
Casos de teste não podem ser 
revisados
Não é possível demonstrar que 
testes foram executados
Difíceis de reproduzir
Teste de Sistema e Requisitos
• Testes de sistemas são usualmente realizados tomando como 
base uma especificação de requisitos
• Dada sua familiaridade intuitiva, na prática testes de sistema 
tendem a ser uma atividade mais informal do que deveria
▫ Intervalos de teste reduzidos
▫ Testes próximos ao deadline de entrega!
Threads de Comportamento
• Casos de teste são usualmente definidos como threads de 
comportamento:
▫ Um cenário de uso
▫ Uma sequência de pares estímulo-resposta
▫ Um comportamento resultado de uma sequência de entradas ao sistema
▫ Uma sequência de mensagens e 
execuções de métodos
▫ ...
Requisitos
A escrita de requisitos é desafiante, em particular por ser 
usualmente feita em linguagem natural, podendo levar a 
diferentes interpretações:
“O sistema de alarme principal deve soar se detectar a 
presença de um intruso com uma câmera digital”.
Requisitos
Requisitos devem descrever o comportamento esperado do sistema e não como 
este comportamento é produzido
BOM: “Quando o usuário clica no botão “velocidade”, a velocidade atual deve ser exibida na tela principal”.
RUIM: “Quando o usuário clica no botão “velocidade”, o sistema deve acessar a localização de memória 
0x481034810 e exibir seu conteúdo na tela.”
BOM: “O sistema deve poder operar com uma velocidade de 0.8c por no mínimo 300 dias sem necessitar 
de manutenção”.
RUIM: “O sistema deve usar uma reação anti-matéria a fim de atingir a velocidade 0.8c.”
Requisitos e Testabilidade
“O sistema deve incrementar o 
contador de ingresso sempre que um 
sensor de presença for ativado sem 
erro.”
“O sistema deve realizar tarefas com 
o contador de ingresso sempre que 
alguém entrar na sala.”
Requisitos devem ser:
Completos
Consistentes
Não-ambíguos
Quantificáveis
Viáveis para teste
Testes como Requisitos
Comumente aplicado na comunidade ágil
Objetivos podem ser conflitantes, visto que casos de teste 
devem descrever usos específicos do sistema.
Teste Manual
Teste Automático
Teste Manual: Vantagens
Simplicidade
Baixo Custo
Não demanda codificação adicional de software
Flexibilidade
Maior possibilidade de testar preocupações do usuário
Captura de defeitos não observáveis de forma automática
Teste Manual: Desvantagens
Chato/Tedioso
Pode ser não repetível / reproduzível
Algumas tarefas são difíceis ou impossíveis de serem testadas de forma manual
Possibilidade de erro humano
Execução de alto custo
Limita a black-box e grey-box
Teste Automático: Vantagens
Elimina erro humano na execução
Execução rápida e feito o setup, fácil de executar
Repetível
Processo simples de analisar
Menor custo de execução
Ideal para testar partes do sistema onde teste manual não pode ser aplicado
Lida bem com alta escala
Teste Automático: Desvantagens
Tempo extra de setup
Pode não capturar certos defeitos
Requer treinamento na escrita de casos de teste e ferramentas de suporte
Requer maior conhecimento tecnológico
Não consegue generalizar ou explorar outros objetivos durante a execução
Suites podem conter testes inúteis ou inválidos.
Manual versus Automático
Práticas complementares
Em situações onde ambos podem ser aplicados, é importante considerar:
● O quão crítico é o software?
● Com que frequência testes serão executados?
● Qual a experiência da equipe?
● Qual o orçamento para teste?
● Qual a dificuldade para automatizar testes? 
● O quão estável são os requisitos do software?
Teste Baseado em Modelos (MBT)
Abordagem de teste que faz uso de modelos, geralmente denominados como 
modelos de teste, para representar o comportamento que queremos testar.
A partir do modelo de teste, os casos de teste são gerados de acordo com um 
determinado critério de teste.
Quando modelos formais são considerados para gerar casos de teste e abstrair 
detalhes do SUT, essa abordagem é comumente conhecida como teste de 
conformidade.
Teste Baseado em Modelos (MBT)
Teste Baseado em Modelos (MBT): Benefícios
● Maior eficácia nos testes, levando a um foco e cobertura justa / sistemática 
do que precisa ser testado;
● Redução de custos de testes, pela possível reutilização de artefatos de 
desenvolvimento e automação de geração de artefatos de testes;
● Maior confiabilidade nos testes devido ao fato de que a maioria dos artefatos 
de teste é gerada automaticamente em contraste com a codificação manual 
deles.
Teste Baseado em Modelos (MBT): Desafios
● Modelar pode ser muito difícil
● Modelos explodem (quando a ferramenta em uso não é dimensionada para 
modelos complexos)
● Testes gerados podem não detectar todos os defeitos se modelos não 
estiverem alinhados/atualizados com o código.
CLARET
• CentraL Artifact for RE and mbT notation
• Processo e ferramenta para especificação de requisitos 
e geração automática de suites de teste de sistema
▫ Trabalho de mestrado de Dalton Jorge
• Objetivo: 
▫ Agilizar a especificação de requisitos no contexto ágil
▫ Aplicação de Model-based Testing no contexto ágil
CLARET
• DSL para especificação de requisitos via casos de uso
▫ Simples
▫ Linguagem próxima ao desenvolvedor
▫ Baseada nos pares estímulo/resposta
▫ Permite a modelagem de comportamentos alternativos e de exceção
▫ Pensadapara auxiliar a geração de testes
CLARET - Processo
CLARET
• DSL para especificação de requisitos via casos de uso
Sistema: Receita Federal
Funcionalidade: Incluir novo CPF
O usuário seleciona a opção para incluir CPF no menu principal. O 
sistema deve validar o CPF e, sendo válido, incluí-lo e apresentar 
mensagem indicando que foi aceito. Durante a inserção do CPF o 
usuário poderá cancelar a operação
TGF Gerado
XML com a Suite Gerada
CLARET na Prática
• Aplicado projetos reais
• Antes:
▫ Não existia especificação dos requisitos organizada
▫ Somente testes exploratórios eram realizados
▫ Cliente reportava as falhas
CLARET na Prática
Sistema # de Use Cases # de Casos de Teste
A 17 56
B 19 63
C 12 32
• Resultados de execução: