AULA 3 - QUALIDADE E TESTE DE SOFTWARE - 09_03_2021

Prévia do material em texto

Aula 3 - Qualidade e Teste de 
Software
DATA: 09/03/2021
Os testes de software são uma maneira de garantir a qualidade
de um software. Com isso existem diversas maneiras de se testar
um sistema, que podem variar de acordo com a sua natureza ou
seu objetivo. Pode-se classificar em:
1.Testes estruturais ou caixa-branca (white-box testing): teste de
unidade e teste de integração.
2.Testes funcionais ou caixa-preta (black-box testing): teste de
sistema e teste de aceitação.
3.Testes não-funcionais: teste de carga e teste de segurança.
4.Testes de regressão: teste de manutenção e teste de confirmação.
Estratégias de Teste de Software
Estratégias de Teste de Software
Atualmente existem muitas maneiras de se testar um software.
Mesmo assim, existem as técnicas que sempre foram muito
utilizadas em sistemas desenvolvidos sobre técnicas estruturadas
que ainda hoje tem grande valia para os sistemas orientados a
objeto.
Apesar de os paradigmas de desenvolvimento serem completamente
diferentes, o objetivo principal destas técnicas continua a ser o
mesmo que é: encontrar falhas no software.
Técnicas de Teste de Software
1. Caixa-Branca;
2. Caixa-Preta;
3. Caixa-Cinza.
CAIXA PRETA - Neste tipo 
de teste de software o 
desenvolvedor dos 
testes não possui 
acesso algum ao 
código fonte do
programa.
CAIXA BRANCA - Dentro
desta categoria de teste 
de software o 
desenvolvedor tem
acesso ao código fonte 
da aplicação e pode 
construir códigos para
efetuar LINKER de
componentes.
Técnicas 
popularizadas pelo 
mercado de software
Caixa Preta
Abaixo estão as três técnicas mais conhecidas.
CAIXA CINZA - Uma
definição deste tipo de 
teste seria um ponto de 
equilíbrio virtual entre o 
teste de caixa-branca e o 
caixa-preta. .
Técnicas de Teste de Software
Técnicas de Teste de Software
Caixa-Branca (White Box)
Este tipo de teste é desenvolvido analisando-se o código fonte e elaborando-
se casos de teste que cubram todas as possibilidades do programa.
Dessa maneira, todas as variações originadas por estruturas de condições são 
testadas. Um exemplo bem prático deste teste é o JUnit para desenvolvimento 
com a linguagem Java e para a linguagem .NET o Project Analyzer.
Técnicas de Teste de Software
http://pt.wikipedia.org/wiki/JUnit
http://pt.wikipedia.org/wiki/Linguagem_de_programa?%3Fo_Java
http://pt.wikipedia.org/wiki/Microsoft_.NET
http://www.aivosto.com/project/project.html
http://www.aivosto.com/project/project.html
O teste da caixa branca exige mais conhecimento técnico por parte do
testador, sem contar o maior custo. Existem algumas práticas que visam
amplificar a efetividade dessa técnica. Desse modo, abaixo seguem dois
exemplos: teste de condição e teste de ciclo.
Teste de condição
Essa técnica é simples, pois sua proposta é avaliar se os
operadores/variáveis lógicos (booleanos – true/false) estão consistentes.
Teste de ciclo
Verificação/teste de estrutura de repetição (for/while). De modo bem
simples, é justamente isso que essa técnica faz: valida estruturas de
repetição.
Técnicas de Teste de Software
Para isso, ela divide os ciclos em 4 tipos: desestruturado, simples, aninhado
e concatenado.
1. Ciclo desestruturado nada mais é do que o conjunto de blocos de
repetição utilizados de maneira desordenada. Por conta disso, ao ser
identificado, deve ser reestruturado, já que aumenta consideravelmente
o custo dos testes e da manutenção do sistema.
2. Ciclo simples, como o próprio nome diz, é apenas uma estrutura de
repetição sendo testada.
3. Ciclos aninhados são ciclos dentro de ciclos.
4. Ciclos concatenados são estruturas de repetição dependentes, ou seja,
para testar o bloco 2, eu preciso garantir que o bloco 1 é coerente.
Teste da caixa branca 
Técnicas de Teste de Software
Caixa-Preta (Black Box)
O objetivo é efetuar operações sobre as diversas funcionalidades e verificar
se o resultado gerado por estas está de acordo com o esperado.
Para esta categoria podem ser levados em consideração todos os eventos que
podem ser disparados pelo usuário, como por exemplo, cada clique de mouse
a ser realizado em uma interface.
Exemplos de teste caixa preta:
• Teste de Classe de Equivalência;
• Teste de Análise de Valor Limite;
• Teste de Tabela de Decisão.
Técnicas de Teste de Software
Parte do princípio utilizando-se da experiência do usuário, ou seja, através
da interface do produto.
Com isso, para aumentarmos a qualidade e, consequentemente,
blindarmos o software de falhas, entendemos que todas as entradas/saídas
possíveis precisam ser testadas, mas na grande parte dos casos esse
processo não é possível.
Ademais, a falta de clareza dos requisitos acaba impactando nas entradas
e saídas aceitas para o teste.
Teste da caixa preta
Técnicas de Teste de Software
Teste da caixa preta
Técnicas de Teste de Software
O particionamento de equivalência divide as entradas do usuário na
aplicação em partições (também conhecidas como classes de equivalência) e
então as divide em faixas de valores possíveis, para que então, um desses
valores seja eleito como base para o teste. Existem partições de equivalência
para valores válidos e inválidos.
Valores válidos são valores que devem ser aceitos pelo sistema. Uma partição
de equivalência contendo este tipo de valor é chamada de “partição de
equivalência válida”.
Valores inválidos são valores que devem ser rejeitados pelo sistema. Uma
partição de equivalência contendo estes valores é chamada de “partição de
equivalência inválida”.
Considere que na sua empresa há um sistema de recursos humanos que processa
pedidos de emprego com base na idade de uma pessoa e que possui as seguintes
regras de negócio:
•Pessoas menores de 16 anos não devem trabalhar.
•Pessoas entre 16 e 80 anos podem trabalhar.
•Pessoas com mais de 80 anos não podem trabalhar.
Dividindo estas regras em entradas possíveis para o sistema, tem-se:
16 – 80 anos
Teste da caixa preta
Técnicas de Teste de Software
0 – 15 anos 81 ou mais anos
87
Teste da caixa preta
Técnicas de Teste de Software
Com esses valores, espera-se que:
• Se um caso de teste em uma classe de equivalência detectar um defeito, todos
os outros casos de teste na mesma classe de equivalência provavelmente
detectarão o mesmo defeito.
• Se um caso de teste em uma classe de equivalência não detectar um defeito,
nenhum outro caso de teste na mesma classe de equivalência é provável que
detecte o defeito.
Análise de valor limite
Essa técnica sugere que sejam utilizados apenas os valores que estejam
no limite permitido.
Assim, se você quer validar, por exemplo, que para uma dada operação
o usuário deve ter idade superior a dezoito anos, os melhores valores
para o teste são: 17, 18 e 19, já que estão no limite do valor mínimo
permitido (18).
Teste da caixa preta
Técnicas de Teste de Software
Tabela de decisão
Pressuponha que você testará uma funcionalidade que possui uma série de
condições. Agora, como saber se todos os casos estão apresentando as saídas
esperadas?
Teste da caixa preta
Técnicas de Teste de Software
Para facilitar, imagine o teste de uma baixa de estoque:
A tabela de decisão se baseia na verificação do resultado esperado para os conjuntos formados
através da combinação desses parâmetros.
De acordo com o exemplo, temos certeza que ao menos 3 das combinações possíveis possuem
cobertura por 3 testes.
Teste da caixa preta
Técnicas de Teste de Software
Caixa-Cinza (Gray Box)
Esta técnica aparece com muitas interpretações na literatura de testes.
De uma maneira mais clara, o desenvolvedor dos testes não tem acesso ao código
fonte da aplicação, porém tem conhecimento dos algoritmos que foram
implementados, como também pode efetuar manipulações em arquivos de entrada e
saída do tipo XML ou mesmo acessos ao banco de dados da aplicação para simples
conferência de dados ou alteração de parâmetros considerados nos casos de teste.
Outros autores definem caixa-cinza como o teste de integração, onde você vê o
sistema até o nível de módulo, masnão pode ver no interior dos módulos.
Ainda é possível encontrar a definição de caixa-cinza como um teste onde algumas
partes estão disponíveis como caixa-branca e outras como caixa-preta.
Técnicas de Teste de Software
Técnicas de Teste de Software
Te
st
e 
d
e
b
ai
xo
 n
ív
el
Te
st
e 
d
e
al
to
 n
ív
el
Níveis de teste de software
• Os testes devem ser executados em diferentes níveis, visando
avaliar o software em diferentes perspectivas de acordo com o
produto gerado em cada fase do ciclo de vida de
desenvolvimento de um software.
– Testes de unidade: as menores unidades funcionam
corretamente?
– Testes de integração: quando integradas elas continuam a
produzir o resultado esperado ?
– Testes de validação: (ou aceitação) o programa produz o resultado
esperado pelo usuário?
– Testes de sistema: o programa funciona como esperado no
seu ambiente como todo ?
Testes de unidade
Código
Níveis de teste de software
Testes de integação
Testes de unidade
Código 
Projeto
Níveis de teste de software
Testes de validação 
Testes de integação
Testes de unidade
Código 
Projeto
Requisitos
Níveis de teste de software
Teste de sistema 
Testes de validação 
Testes de integação
Testes de unidade
Código 
Projeto
Requisitos 
Engenharia de sistemas
Níveis de teste de software
Níveis de teste de software
Teste de Regressão não corresponde a um nível de teste, mas
é uma estratégia importante para redução de “efeitos
colaterais”.
Consiste em se aplicar, a cada nova versão do software ou a cada
ciclo, todos os testes que já foram aplicados nas versões ou ciclos de
teste anteriores do sistema.
Pode ser aplicado em qualquer nível de teste.
Testes de unidade
• Tem como propósito testar a menor unidade do
programa.
• Usa-se a descrição do projeto no nível da
unidade como guia para os testes.
• Os erros estarão nos limites destas unidades.
• Pode ser conduzido em paralelo para diversas
unidades.
Testes de unidade
Casos de teste
Unidade Interface
Estruturas de dados 
Condições limites 
Caminhos independentes
Caminhos de manipulação de erros
Testes de unidade
• Interface, é testada para garantir que a informação flui
adequadamente para dentro e para fora da unidade do
programa.
• Estrutura de dados, é examinada para garantir que os
dados armazenados temporariamente mantenham sua
integridade durante todos os passos do programa.
• As condições-limites são testadas para garantir que a
unidade opere adequadamente nos limiares.
• Todos os caminhos independentes (básicos) são exercitados
para garantir que que todos os comandos tenham sido
executados.
• Todos os caminhos de manipulação de erros são testados.
Testes de unidade: Interface
• Testes de fluxo de dados entre as interfaces são necessários
antes de qualquer outro teste.
• Se os dados não entram e nem saem
adequadamente, todo os testes são discutíveis.
Testes de unidade: ED
• As estruturas de dados (ED) locais devem ser
exercitadas.
• O impacto local nos dados globais devem ser
verificados (se possível) durante o teste de unidade.
Teste de unidade: teste de caminho
• Casos de testes devem ser projetados para descobrir
erros devidos a cálculos errados, comparações
incorretas ou fluxo de controle inadequado.
• Exemplos:
– Inicialização incorreta, representação incorreta de
uma expressão, erros de operadores ou
precedência, variáveis de ciclo inadequadamente
modificada e etc.
Teste de unidade: limites
• Teste nos limites é uma das mais importantes tarefas
do teste de unidade.
• O software frequentemente falha nos limites:
– N-esimo elemento de um vetor de dimensão N é
processado, a I-esima repetição de um ciclo com I
passagens, valor máximo ou mínimo é encontrado
e etc.
Teste de unidade: exceção
• Erros potenciais no tratamento de erro (ou
exceção):
1. Descrição de erro ininteligível (não se
compreende).
2. Erro mencionado não corresponde ao erro
encontrado.
3. A condição de erro provoca a intervenção do
sistema antes da manipulação de erro.
4. O processamento da condição de exceção de erro
esta incorreto.
5. A descrição de erro não fornece informação
suficiente para encontrar o defeito.
Testes de unidade: procedimento
• Normalmente considerado um apêndice ao passo
de codificação.
• O projeto de teste pode ser realizado antes que o
código seja iniciado (abordagem ágil).
• Cada caso de teste deve ser acoplado a um conjunto
de resultados esperados.
Se minhas unidades funcionam 
como o esperado, não significa que
meu software irá funcionar como o
esperado ?
Testes de integração
• Infelizmente, software é um sistema
complexo. Defeitos de projetos podem:
–Perder dados entre as interfaces (ex: dados
incompátiveis).
–Efeito imprevisto ou adverso sobre o outro (ex:
variáveis globais).
–Subfunções quando integradas podem não
produzir o resultado esperado pela função
principal.
–Etc.
Testes de integração
• Infelizmente, software é um sistema
complexo. Defeitos de projetos podem:
–Perder dados entre as interfaces (ex: dados
incompátiveis).
–Efeito imprevisto ou adverso sobre o outro (ex:
variáveis globais).
–Subfunções quando integradas podem não
produzir o resultado esperado pela função
principal.
–Etc.
Testes de integração
• Técnica sistemática (método de formar um todo
organizado) para construir a arquitetura do software
e ao mesmo tempo, conduz testes para descobrir
falhas associadas a interface.
• Abordagens:
– a) Não incremental e b) incremental
Testes de integração: não incremental
• A integração não incremental, ou seja, a
abordagem big-bang.
–Todos os componentes são integrados e o sistema é
testado.
–Não existe uma abordagem sistemática para
integração
• Abordagem caótica, um conjunto de falhas é
identificada e a correção é difícil, pois o isolamento
das causas é complicado.
Testes de integração: incremental
• Antítese da abordagem big-bang. O programa é construído
e testado em pequenos incrementos, em que os erros são
mais fáceis de isolar e corrigir:
– Integração descendente (top-down), as unidades são
integradas movendo descendentemente pela hierarquia,
começa pela unidade principal (programa principal) e
dela as unidades subordinadas.
– Integração ascendente (bottom-up), inicia o teste com as
unidades atômicas (níveis mais baixos do programa) e
são integrados de baixo para cima.
Integração top-down
M1
M2 M3 M4
M7M5 M6
M8
Primeiro-em-profundidade vs Primeiro-em-largura
Integração bottom-up
• Os componentes são integrados de baixo para cima,
as unidades subordinadas estão sempre disponíveis.
• Necessidades de pseudocontrolados é
eliminada.
• Pseudocontroladores são necessários.
Integração bottom-up
1. Componentes de baixo nível são combinados em
agregados (clusters, algumas vezes chamados de
construções) que realizam uma subfunção
especifica.
2. Um pseudocontrolador é escrito para coordenar a
entrada e a saída dos casos de teste.
3. O agregado e testado.
4. Pseudocontroladores são removidos e
agregados são combinados movendo-se para
cima da estrutura do programa.
Testes de integração em OO
• Em OO os objetos se relacionam e colaboram em tempo de
execução de modo não obvio.
• A abordagem convencional não é efetiva.
• Duas estratégias:
–Testes baseados na execução, integra um conjunto de
classes necessárias para responde uma entrada ou um
evento do sistema.
–Testes baseado no uso, testam as classes
independentes e depois as dependentes.
Testes de validação
• Começa no fim do teste de integração, quando o
software está completamente montado.
• Na validação não existe distinção de
paradigmas.
• O teste focaliza ações visíveis ao usuário e saídas do
sistema reconhecida pelo usuário.
Testes de validação
• Uma validação se torna bem sucedida, quando o
software funciona de modo que pode ser
razoavelmente esperado pelo usuário.