UESA-Testes de Software-Tipos-Testes-2021-1

Prévia do material em texto

Qualidade e Teste de Software
CCT-0711
Prof. Jose Guilherme
2021.1
Estratégia de Teste de Software
Teste é um conjunto de atividades que pode ser
planejado antecipadamente e realizado
sistematicamente. O planejamento e a realização
das atividades de teste definem a estratégia de
testes de software.
Uma estratégia de teste de software define
técnicas de projeto de casos de teste e métodos
de teste específicos para cada etapa do processo
de engenharia de software.
Uma Estratégia de Teste deve acomodar testes
de baixo nível e testes de alto nível, deve
oferecer orientação ao profissional, deve
oferecer um conjunto de marcos de referência
ao administrador e deve ser mensurável.
Estratégia de Teste de Software
Características Genéricas de Estratégias de
Teste:
 A atividade de teste inicia-se no nível de
módulos e prossegue "para fora", na direção da
integração de todo o sistema.
 Diferentes técnicas de teste são apropriadas
a diferentes pontos de tempo.
Estratégia de Teste de Software
 A atividade de teste é realizada pela equipe
de desenvolvimento do software e para grandes
projetos por um grupo de teste independente.
 As atividades de teste e de depuração são
atividades diferentes, mas a depuração deve
ser acomodada em qualquer estratégia de
teste.
deve ser mensurável.
Estratégia de Teste de Software
Verificação e Validação
A atividade de teste de software é um elemento
de um tema mais amplo chamado Verificação e
Validação (V&V).
 VERIFICAÇÃO - refere-se ao conjunto de
atividades que garante que o software
implemente corretamente um função específica.
Verificação e Validação
VALIDAÇÃO - refere-se ao conjunto de
atividades que garante que o software que foi
construído é rastreável às exigências do cliente.
A definição de V&V abrange muitas das
atividades às quais nos referimos como garantia
da qualidade de software (SQA).
Garantia da Qualidade de Software
Métodos de Engenharia de Software:
proporcionam a base a partir da qual a
qualidade é construída.
Revisões Técnicas Formais: ajudam a garantir
a qualidade do produto produzido como uma
conseqüência de cada passo da engenharia de
software.
Medição: ajudam a controlar cada elemento
da configuração de software.
Garantia da Qualidade de Software
Padrões e Procedimentos: ajudam a garantir a
uniformidade.
Garantia de Qualidade de Software (SQA):
põe em prática uma filosofia de qualidade total.
 Teste: a qualidade pode ser avaliada.
Garantia da Qualidade de Software
Organização para Realização de Teste 
de Software
Quando o teste se inicia há um conflito de
interesses:
Desenvolvedores: têm interesse de
demonstrar que o programa é isento de erros.
Os responsáveis pelos testes: têm interesse
em mostrar que o programa tem erros.
Do ponto de vista psicológico:
 Análise, Projeto e Codificação de Software
são tarefas construtivas.
Teste é tarefa destrutiva.
Organização para Realização de Teste 
de Software
Para suprir o conflito de interesses existe o
Grupo Independente de Testes (ITG).
O ITG faz parte da equipe de projeto de
desenvolvimento de software, no sentido de
que está envolvido durante o processo de
especificação e continua envolvido planejando
e especificando procedimentos de teste ao
longo de um grande projeto.
Organização para Realização de Teste 
de Software
Uma Estratégia de Teste de Software
Teste de Unidade: concentra-se em cada
unidade do software, de acordo com o que é
implementado no código fonte.
Teste de Integração: concentra-se no projeto e
na construção da arquitetura de software.
Uma Estratégia de Teste de Software
Teste de Validação: os requisitos
estabelecidos com o parte da análise de
requisitos de software são validados em relação
ao software que foi construído.
Teste de Sistema: o software e outros
elementos do sistema são testados como um
todo.
Uma Estratégia de Teste de Software
Etapas do Teste de Software
 Testes de Unidade: Cada módulo é testado
individualmente garantindo que ele funcione
adequadamente. Utiliza as técnicas de teste de
caixa branca.
 Testes de Integração: Os módulos são
montados ou integrados para formarem um
pacote de software. Utiliza principalmente as
técnicas de teste de caixa preta.
Etapas do Teste de Software
 Testes de Alto Nível: Os critérios de
validação estabelecidos durante a análise de
requisitos são testados. Verifica também se
todos os elementos combinam-se
adequadamente e se a função/ desempenho
global do sistema é conseguida. Utiliza as
técnicas de caixa preta.
Etapas do Teste de Software
Critérios para a Conclusão de Teste
Quando realizamos testes, como saber se já
testamos o suficiente?
Respostas pragmáticas:
Você jamais terá completado a atividade de
teste; a carga simplesmente transfere-se do
projetista para o cliente.
Quando estiver sem tempo ou sem dinheiro.
Critérios para a Conclusão de Teste
Teste de Unidade
 A interface com o módulo é testada para ter a
garantia de que as informações fluem para
dentro e para fora da unidade de programa que
se encontra sob teste.
 A estrutura de dados local é examinada para
ter a garantia de que dados armazenados
temporariamente mantêm sua integridade
durante todos os passos de execução.
Teste de Unidade
 As condições de limite são testadas para ter a
garantia de que o módulo opera
adequadamente nos limites estabelecidos para
demarcarem ou restringirem o processamento.
 Todos os caminhos independentes através da
estrutura de controle são exercitados para ter a
garantia de que todas as instruções de um
módulo foram executadas pelo menos uma vez.
Teste de Unidade
 Todos os caminhos de tratamento de erros
são testados.
Teste de Unidade - Ambiente
Um vez que o módulo não é um programa
individual, um software driver e/ou stub deve
ser desenvolvido para cada unidade de teste.
 Driver - na maioria das aplicações é um
programa principal que aceita dados de caso de
teste, passa tais dados para o módulo a ser
testado e imprime os dados relevantes.
Teste de Unidade - Ambiente
 Stub ou programa simulado - servem para
substituir módulos que estejam subordinados
(chamados pelo) ao módulo a ser testado. Usa
a interface do módulo subordinado, pode fazer
manipulação de dados mínima, imprime
verificação de entrada e retorna.
Teste de Unidade - Ambiente
Teste de Integração
É uma técnica sistemática para a construção da
estrutura de programa, realizando-se, ao
mesmo tempo, testes para descobrir erros
associados a interfaces.
O objetivo é, a partir dos módulos testados ao
nível de unidade, construir a estrutura de
programa que foi determinada pelo projeto.
Teste de Integração
Integração não incremental: abordagem "big-
bang". O programa completo é testado como
um todo e o resultado é o caos. Quando erros
são encontrados, a correção é difícil porque o
isolamento das causas é complicado pela vasta
amplitude do programa inteiro.
Teste de Integração
Integração Incremental: o programa é
construído e testado em pequenos segmentos,
onde os erros são mais fáceis de serem
isolados e corrigidos; as interfaces têm maior
probabilidade de serem testadas
completamente e uma abordagem sistemática
ao teste pode ser aplicada.
Teste de Integração
Integração Top-Down
Os módulos são integrados movimentando-se
de cima para baixo, através da hierarquia de
controle, iniciando-se do módulo de controle
principal.
Os módulos subordinados ao módulo de
controle principal são incorporados à estrutura
de uma maneira depth-first (primeiro pela
profundidade) ou breadth-first (primeiramente
pela largura).
Teste de Integração
Integração Top-Down
Teste de Integração
Integração Top-Down
Teste de Validação
Ao término da atividade de teste de integração,
o software está completamente montado como
um pacote, erros de interface foram
descobertos e corrigidos e uma série final de
testes de software - os testes de validação -
pode iniciar-se.
Teste de Validação
A validação é bem sucedida quando o software
funciona de uma maneira razoavelmenteesperada pelo cliente.
A Especificação de Requisitos de Software
contém os critérios de validação que formam a
base para uma abordagem ao teste de
validação.
Teste de Validação
A validação do software é realizada por meio de
uma série de testes de caixa preta que
demonstram a conformidade com os requisitos.
O plano e o procedimento de teste são
projetados para garantir que:
todos os requisitos funcionais são satisfeitos
Teste de Validação
todos os requisitos de desempenho são
conseguidos
a documentação está correta
outros requisitos são cumpridos: portabilidade,
compatibilidade, remoção de erros e
manutenibilidade
Um elemento importante do processo de
validação é a revisão de configuração ou
auditoria.
O propósito dessa revisão é garantir que todos
os elementos da configuração de software
tenham sido adequadamente desenvolvidos,
estão catalogados e têm os detalhes
necessários para apoiar a fase de manutenção
do ciclo de vida do software.
Teste de Validação
Revisão de Configuração
É virtualmente impossível que se preveja como
o cliente realmente usará um programa. As
instruções de uso podem ser mal-interpretadas,
combinações estranhas de dados podem ser
regularmente usadas, saídas que pareciam
claras ao analista podem ser ininteligíveis para
um usuário em campo.
Teste de Validação
Testes Alfa e Beta
Software Customizado para um Cliente
 são realizados testes de aceitação, realizados
pelo usuário final para capacitá-lo e para validar
todos os requisitos.
 pode variar de um test drive informal a uma
série de testes planejados.
Teste de Validação
Testes Alfa e Beta
Software Desenvolvido como um Produto
para Muitos Clientes
Teste Alfa - É levado a efeito por um cliente
nas instalações do desenvolvedor. O software é
usado num ambiente controlado com o
desenvolvedor observando a utilização pelo
usuário e registrando erros e problemas de uso.
Teste de Validação
Testes Alfa e Beta
Software Desenvolvido como um Produto
para Muitos Clientes
Teste Beta - é realizado nas instalações do
cliente pelo usuário final do software. O
desenvolvedor não está presente. O cliente
registra os problemas (reais ou imaginários) que
são encontrados e relata-os ao desenvolvedor
a intervalos regulares.
Teste de Validação
Testes Alfa e Beta
O software é apenas um elemento de um
sistema baseado em computador mais amplo.
O teste de sistema envolve uma série de
diferentes testes, cujo propósito primordial é por
completamente à prova o sistema baseado em
computador.
Teste de Sistema
Problema Clássico da atividade de teste de
sistema:
"apontar o dedo" - quando ocorre um erro, o
desenvolvedor de um elemento do sistema
culpa outro pelo problema.
Teste de Sistema
O engenheiro de software deve antecipar os
problemas potenciais da interface:
1- projetar caminhos de tratamento de erros
que testem todas as informações que chegam
de outros elementos do sistema.
2- realizar uma série de testes que simulem
dados ruins ou outros erros em potencial na
interface do software.
Teste de Sistema
3- registrar os resultados de teste para usar
como "prova" se alguém lhe apontar o dedo.
4- participar do planejamento e projeto dos
testes do sistema para garantir que o software
seja adequadamente testado.
Teste de Sistema
Muitos sistemas baseados em computador
precisam recuperar-se de falhas e retomar o
processamento dentro de um tempo
previamente especificado.
Em certos casos, o sistema deve tolerar falhas,
isto é, o processamento de falhas não deve
fazer com que uma função global de sistema
cesse.
Teste de Sistema
Teste de Recuperação
Em outros casos, uma falha do sistema deve
ser corrigida dentro de um período previamente
especificado; caso contrário, graves prejuízos
econômicos ocorrerão.
O teste de recuperação é um teste de sistema
que força o software a falhar de diversas
maneiras e verifica se a recuperação é
adequadamente executada.
Teste de Sistema
Teste de Recuperação
Qualquer sistema baseado em computador que
gerencie informações delicadas ou provoque
ações que possam impropriamente prejudicar
(ou beneficiar) pessoas constitui um alvo para o
acesso impróprio ou ilegal.
O teste de segurança tenta verificar se todos os
mecanismos de proteção embutidos num
sistema o protegerão, de fato, de acessos
indevidos.
Teste de Sistema
Teste de Segurança
Durante o teste de segurança, o analista
desempenha o papel de pessoa que deseja
penetrar no sistema. Qualquer coisa vale!
adquirir senhas mediante contatos externos
 atacar o sistema com software customizado 
projetado para derrubar quaisquer defesas que 
tenham sido construídas
Teste de Sistema
Teste de Segurança
desarmar o sistema, negando serviço a outros
provocar erros intencionalmente, esperando
acessá-lo durante a recuperação
O papel do projetista do sistema é fazer com
que o acesso custe mais do que o valor da
informação que será obtida.
Teste de Sistema
Teste de Segurança
O objetivo primordial da Depuração é descobrir
e corrigir a causa de um erro de software.
A depuração ocorre em conseqüência de testes
bem sucedidos. Embora a depuração possa e
deva ser ser um processo disciplinado, ela
ainda tem muito de arte.
A Arte da Depuração
Debugging
A Arte da Depuração
Debugging
Durante a depuração, encontram-se erros que
variam de brandamente perturbadores a
catastróficos.
À medida que as conseqüências de um erro
aumenta, a pressão para descobrir a causa
também aumenta.
Depuração
O Processo de Depuração
POR QUE A DEPURAÇÃO É TÃO DIFÍCIL?
1- O sintoma e a causa podem ser
geograficamente remotos. Estruturas altamente
acopladas agravam essa situação.
2- O sintoma pode desaparecer
(temporariamente) quando outro erro é
corrigido.
Depuração
O Processo de Depuração
3- O sintoma pode, de fato, ser causado por
não erros (por exemplo, imprecisões de
arredondamento).
4- O sintoma pode ser causado por um erro
humano que não é facilmente rastreado.
5- O sintoma pode ser resultado de problemas
de timing, e não problemas de processamento.
Depuração
O Processo de Depuração
6- O sintoma pode ser devido a causas que
estão distribuídas por uma série de tarefas que
são executadas em diferentes processadores.
Depuração
O Processo de Depuração
1- FORÇA BRUTA:
A categoria de depuração por força bruta
provavelmente é o método mais comum e
menos eficiente de isolar a causa de um erro de
software.
Aplica-se o método de força bruta quando tudo
o mais falha.
Depuração
Abordagens à Depuração
1- FORÇA BRUTA:
Usa-se uma filosofia do tipo "deixe que o
computador descubra o erro". Por exemplo, são
feitas listagens de memória (memory dumps),
são inseridas instruções WRITE, etc.
Espera-se encontrar, em algum lugar do
emaranhado de informações, uma pista que
possa levar à causa de um erro.
Depuração
Abordagens à Depuração
1- FORÇA BRUTA:
Não obstante, a massa de informações
produzida possa levar ao sucesso, mais
freqüentemente ela conduz a tempo e esforço
desperdiçados.
Deve-se gastar o raciocínio primeiro.
Depuração
Abordagens à Depuração
2- BACKTRACKING:
É uma abordagem que pode ser usada com
sucesso em pequenos programas.
Iniciando-se no local em que o sintoma foi
descoberto, o código fonte é rastreado para trás
(manualmente) até que o local da causa seja
encontrado.
Depuração
Abordagens à Depuração
2- BACKTRACKING:
Infelizmente, à medida que o número de linhas
de código aumenta, o número de potenciais
caminhos de backtracking pode tornar-se
incontrolavelmente alto.
Depuração
Abordagens à Depuração
3- ELIMINAÇÃO DA CAUSA:
Os dados relacionados à ocorrência de erros
são organizados para isolar potenciais causas.
Uma "hipótese de causa" é imaginada e os
dados são usados para provar ou refutar a
hipótese.
Depuração
Abordagens à Depuração
3- ELIMINAÇÃO DA CAUSA:
Alternativamente, uma lista de todas as causas
possíveis é desenvolvida e testes são
realizados para eliminar cada uma.
Se os testes iniciais indicarem que uma
hipótese de causa apresenta possibilidades, os
dados são refinados,numa tentativa de isolar o
bug.
Depuração
Abordagens à Depuração
As abordagens de depuração podem ser
complementadas com ferramentas de
depuração: compiladores de depuração, auxílio
rastreadores de depuração dinâmicos,
geradores de casos de teste automáticos,
geradores de dumps de memória e geradores
de mapas de referência cruzada.
Depuração
Conclusões
Um poderoso aliado à depuração são "outras
pessoas". O conceito de "programação não
egoística"de Weinberg deve ser ampliado para
"depuração não egoística".
Depuração
Conclusões
Assim que um erro é encontrado, ele deve ser
corrigido, porém a correção de um erro pode
introduzir outros erros. Assim, deve-se fazer 3
perguntas simples, sempre que se realizar uma
"correção" que removerá a causa de um erro:
Depuração
Conclusões
1- A causa do bug é reproduzida em outra parte
do programa?
2- Qual "bug seguinte" poderia ser introduzido
pelo reparo que se está prestes a fazer?
3- O que poderia ter sido feito para eliminar
este bug desde o princípio?
Depuração
Conclusões