Testes Soft Und 03

TESTES DE SOFTWARE
Unidade 3 – Teste no Programa

Luiz Leão – luizleao@gmail.com
http://www.luizleao.com
TESTES DE SOFTWARE
Conteúdo Programático
• 3.1 – Depuração
• 3.2 – Teste de Caixa-Branca
• 3.3 – Teste de Caixa-Preta
• 3.4 – Teste de Ambiente Web

TESTES DE SOFTWARE
Introdução
• "Há um mito segundo o qual , se fôssemos realmente bons
para programar , não haveria 'bugs' a ser procurados. Se
pudéssemos realmente nos concentrar, se todos usassem
programação estruturada, projeto 'top-down' , tabelas de
decisão, se tivéssemos as balas de prata certas, então não
haveria 'bugs'." Beizer, 1990 

TESTES DE SOFTWARE
Introdução
• A tarefa de efetuar testes em software foi considerada
secundária por muito tempo.
• Geralmente era vista com o um castigo para o programador,

ou como uma tarefa onde não se deveria gastar muito com
tempo e investimentos.
• O tema esteve relegado a segundo plano, e, até alguns anos

atrás não se encontrava muita literatura sobre o assunto.

TESTES DE SOFTWARE
Introdução
• O objetivo primordial de qualquer técnica para testes é :
MAXIMIZAR (% defeitos encontrados/número de testes feitos)
• As técnicas que vamos estudar auxiliam principalmente na

minimização do número testes.
• Deve-se deixar claro que testar não é a única maneira de se

detectarem erros.
• As técnicas do tipo "walkthroughs" (revisões estruturadas)

quando bem aplicadas chegam a detectar até 60% dos defeitos
existentes.

Depuração
TESTES DE SOFTWARE
Depuração
• Antes de continuar deve ficar bem claro que teste e
depuração são conceitos diferentes.
• Objetivos do Teste: Mostrar que o software tem erros.
• Objetivos da Depuração (Debug): Encontrar a causa do

erro detectado no teste, projetar e implementar as
modificações no programa para correção do erro.

TESTES DE SOFTWARE
Ferramentas de Depuração
• De forma geral, linguagens de alto nível tornam a depuração
mais fácil, pois fornecem mais ferramentas para identificar
erros, como o tratamento de exceções.
– Ex: Java, PHP, .Net, etc. Em ambos os casos as IDEs fornecem a
interface para a depuração
• Em linguagens de baixo nível, erros de código podem causar

problemas difíceis de serem identificados, como corrupção de
memória. Nesse caso, depuradores de memória podem ser
necessários.

TESTES DE SOFTWARE

TESTES DE SOFTWARE

TESTES DE SOFTWARE
Exercício
• Depurar código java para identificarmos onde está ocorrendo
a falha na exibição das respostas esperadas.

Teste de Caixa-Branca
TESTES DE SOFTWARE
• Também conhecidos como Testes Estruturais
• Nesta metodologia os casos de teste são gerados tendo-se

conhecimento da estrutura interna (lógica) do programa, bem
como os seus requisitos.
• É executado na fase de implementação do software

TESTES DE SOFTWARE
• Estudaremos 2 métodos:
– Cobertura Lógica (Critérios Myers)
– Método dos Caminhos Básicos.

TESTES DE SOFTWARE
Cobertura Lógica (Critérios Myers)

• Este método é constituído de critérios que, quando
obedecidos, determinam os casos de teste a serem gerados.
• Os critérios vão se tornando cada vez mais abrangentes e

rigorosos, partindo-se:
– do mais simples, ineficiente e menos rigoroso (Cobertura de
Comandos)
– até o mais complexo, eficiente e rigoroso (Cobertura de Múltiplas

Condições).

TESTES DE SOFTWARE
Cobertura Lógica (Critérios Myers)

• A escolha do critério adequado será norteada pelos seguintes
fatores:
– Complexidade do programa a testar;
– Estrutura do programa a ser testado;
– Criticidade do programa a testar;
– Nível de confiança que se deseja atingir.

TESTES DE SOFTWARE
Complexidade do programa a testar

• Programas mais simples podem ser satisfeitos pela utilização
de critérios menos rigorosos.
• Muitas vezes a utilização de critérios mais rigorosos em

programas muito simples acaba por onerar excessivamente o
processo de testes.

TESTES DE SOFTWARE
Estrutura do programa a ser testado

• Certas estruturas são mais adequadas a determinados
critérios.
• Ex: Programas ricos em comandos, podem ser testados

utilizando-se o critério de cobertura de comandos, programas
com decisões complexas devem ser testados por cobertura de
decisões /condições.

TESTES DE SOFTWARE
Criticidade do programa a testar

• Programas cujo funcionamento não é crítico podem exigir
testes menos rigorosos. Portanto, critérios menos rigorosos
podem ser suficientes para se testar o programa.

TESTES DE SOFTWARE
Nível de confiança que se deseja atingir

• Se o nível de confiança de bom funcionamento é alto, critérios
mais rigorosos são necessários.

TESTES DE SOFTWARE
Coberturas
• Comandos
• Decisões
• Condições
• Decisões-Condições
• Múltiplas Condições

TESTES DE SOFTWARE
Cobertura de Comandos
• Neste critério os casos de teste devem ser gerados de forma
que ao serem executados, o fluxo do programa passe por
todos os COMANDOS existentes no mesmo.
• Ex: Analisar o fluxograma da figura a seguir

TESTES DE SOFTWARE

TESTES DE SOFTWARE
• Um único caso de teste é suficiente para que este critério seja
satisfeito :
– A = 2, B=0 , X qualquer (caminho a c e, passa por todos os comandos, quais
sejam: X = X/ A e X= X + 1)
• O critério é satisfeito, porém, podemos verificar que mesmo para

um programa simples como este ele falha em algumas situações.
Se por exemplo, houvesse os seguintes erros no programa:
– A > 1 OU (no lugar de E) B= 0
– A=2 OU X > 0 (no lugar de 1)
• O caso de teste não detectaria, pois o fluxo do programa continuaria

passando por a c e. A saída do programa estaria inalterada, não
denunciando, portanto, o erro cometido.

TESTES DE SOFTWARE
Cobertura de Decisões
• Neste critério os casos de teste serão gerados de tal forma que
cada decisão tenha todas as suas opções de saída (V ou F)
percorridas ao menos uma vez. Este critério engloba o anterior.
• No exemplo do fluxograma, dois casos de teste são suficientes para

satisfazer este critério:
– A=3, B=0, X=3 faz o fluxo do programa passar por a c d
– A=2, B=1, X=1 faz o fluxo do programa passar por a b e
• Os erros exemplificados no critério anterior seriam detectados.

Porém, observe que se na segunda decisão houvesse um erro
como X < 1 ao invés de X > 1, a saída do programa permaneceria
inalterada, não permitindo a detecção do erro.

TESTES DE SOFTWARE
Cobertura de Condições
• Neste critério os casos de teste são tais que cada condição
em uma decisão deve ser testada ao menos uma vez em
todas as suas saídas possíveis.
• No fluxograma temos as seguintes condições:

– A> 1, B=0, A=2, X > 1
• Temos que gerar casos de teste para testar as situações :

– A>1 e A <=1
– B=0 e B <> 0
– A=2 e A <> 2
– X>1 e X <= 1

TESTES DE SOFTWARE
Cobertura de Condições
• Os seguintes casos de teste satisfazem a estas situações:
– A= 2, B=0, X=3
– A=2, B= 1, X=1
• Observe que com este critério conseguiríamos detectar o erro

descrito no critério anterior.
• Porém ocorre que nem todas as saídas das decisões são

percorridas.

TESTES DE SOFTWARE
Cobertura de Decisões-Condições
• É uma combinação dos dois últimos critérios. Cada condição
em uma decisão é testada em todas as suas saídas possíveis
e cada decisão tem sua saída V ou F percorrida ao menos
uma vez.
• Ainda para o fluxograma da fig. 1 temos que os seguintes

casos de teste satisfazem este critério:
– A= 1, B=1, X= 1 ( satisfaz A <= 1, B<> 0 e X <=1, fazendo com que o fluxo do
programa passe pelo N das duas decisões)
– A= 2, B=0, X= 3 ( satisfaz A > 1, B = 0 e X > 1, fazendo com que o fluxo do
programa passe pelo Y das duas decisões)
• Ocorre que, em algumas situações, uma condição pode
mascarar outras.

TESTES DE SOFTWARE
Cobertura de Múltiplas Condições

• Os casos de teste são tais que todas as combinações de
condições em cada decisão são cobertas.
• Combinações de condições a serem cobertas:

1- A > 1, B= 0 5- A=2, X> 1
2- A > 1, B<>0 6- A=2, X<=1
3- A <= B= 0 7- A<>2, X> 1
4- A > =1 B= 0 8- A<>2, X<= 1
• Os casos de teste que cobrem estas combinações são:

A=2,B=0,X=5 cobre 1,5 
A=2,B=1,X=1 cobre 2,6 
A=1,B=0,X=2 cobre 3,7 
A=1,B=1,X=1 cobre 4,8
TESTES DE SOFTWARE
Cobertura de Múltiplas Condições

• Este é sem dúvida o critério mais abrangente.
• Porém esta abrangência tem um preço: o número de casos de

teste para satisfazê-lo é maior.
• As falhas deste critério estão relacionadas ao número de

caminhos percorridos: ele não garante que este número seja
suficiente para testar com confiança o programa.

TESTES DE SOFTWARE
Método dos Caminhos Básicos

• Método criado pelo matemático norte-americano Thomas
McCabe baseado na teoria de grafos.
• Sua lógica consiste em fazer com que os casos de teste

sejam gerados de forma a fazer com que o fluxo do programa
passe por um número mínimo de caminhos entre a entrada e
a saída do programa, sem o risco de ocorrerem redundâncias.

TESTES DE SOFTWARE
Grafo de Controle
• É um grafo orientado (ou seja, suas arestas possuem setas)
que descreve o fluxo de controle do programa. Na realidade, o
grafo de controle não passa de um fluxograma com símbolos
diferentes, quais sejam:

TESTES DE SOFTWARE
Grafo de Controle
• Por exemplo, o procedimento abaixo terá o seguinte grafo:
procedure Teste(A,B,C : integer);

begin
if A=B then
A:=A+1
else
if B = C then
B:=B+1
else
B:=B -1;
end;
TESTES DE SOFTWARE
Grafo de Controle

TESTES DE SOFTWARE
Caminhos Independentes
• No grafo de controle identificamos os chamados caminhos
independentes.
• Dentre um conjunto de caminhos identificados para um grafo,

dizemos que eles são independentes quando nenhum deles é
formado da combinação de dois ou mais outros.
• Para determinarmos os caminhos independentes de um grafo,

temos que inicialmente determinar quantos são.
• Existem 3 formas de se determinar este número, também

denominado complexidade ciclomática:
TESTES DE SOFTWARE
• 1. Contar o número de regiões no grafo de controle.
• No exemplo da figura, temos três regiões, R1, R2 e R3: as

duas internas(R1 e R2) e a externa (R3).
• Logo, este grafo tem 3 caminhos independentes.

TESTES DE SOFTWARE
• 2. Aplicar a fórmula
C = E-N+2
Onde:
C = número de caminhos independentes
E = número de arestas (Edges)
N = número de nós (Nodes)
• No exemplo da figura temos: 

E = 7, N = 6, logo C = 7-6+2 = 3

TESTES DE SOFTWARE
• 3. Contar o número de estruturas de decisão no programa e
somar 1.
• No exemplo da figura, temos 2 "if". Logo, o número de

caminhos independentes é 3.

TESTES DE SOFTWARE
• Para identificar os caminhos independentes em um grafo
fazemos o seguinte:
• Determinar o número de caminhos independentes conforme visto
anteriormente.
• Tomar o caminho mais a esquerda possível no grafo como primeiro

caminho independente. No exemplo da figura, este caminho é o ac.
• Tomar o próximo caminho à direita, tendo o cuidado de incluir nele

pelo menos uma aresta que não tenha sido incluída nos outros
caminhos já determinados. No exemplo, caminho bdg.
• Repetir o passo anterior até que se obtenham todos os caminhos.

No exemplo, só nos resta o caminho bef.
TESTES DE SOFTWARE
Geração dos Casos de Teste

• Cada caminho obtido dará origem a um caso de teste. Os
casos de teste são gerados de forma que façam com que os
caminhos aos quais correspondam sejam percorridos. No
exemplo da figura temos:
• Caminho ac: Entradas: A=3, B=3, C=3. Saídas: A=4, B=3.

• Caminho bdg: Entradas: A=3, B=4, C=4. Saídas: A=3, B=4.
• Caminho bef: Entradas: A=3, B=5, C=6. Saídas: A=3, B=4.

TESTES DE SOFTWARE
Passos do Método
• Passo 1: Desenhar o grafo de controle
• Passo 2: Determinar o número de caminhos independentes

(complexidade ciclomática)
• Passo 3: Obter os caminhos independentes

TESTES DE SOFTWARE
Passos do Método (Cont.)

• Passo 4: Para cada caminho, gerar os casos de teste,
utilizando a especificação do programa para inferir os
resultados esperados.
• Passo 5:
• Executar cada caso de teste
• Checar os resultados obtidos contra os esperados
• O teste estará completo quando houver confiança absoluta em
que todos os casos de teste obtêm resultados satisfatórios.

Teste de Caixa-Preta
TESTES DE SOFTWARE
• Conhecido também como Teste Comportamental
• O seu foco principal é testar os requisitos funcionais (Software

entregue, Documentos de especificação, regras de negócio,
etc.)
• As técnicas desse tipo de teste permitem derivar série de

condições de entrada que utilizarão completamente todos os
requisitos funcionais para um programa
• O teste Caixa-Preta não é uma alternativa ao Caixa-Branca,

porém, são abordagens complementares.
TESTES DE SOFTWARE
Possíveis Erros a serem encontrados

• Funções incorretas ou incompletas
• Erros de Interface
• Erros em Estruturas de Dados ou de acesso a bases de

dados externas
• Erros de Comportamento ou de Desempenho
• Erros de Inicialização e Termino

TESTES DE SOFTWARE
• Diferentemente do teste Caixa-Branca, que é executado na da
fase de implementação, o teste Caixa-Preta é executado na
fase de teste do projeto.

TESTES DE SOFTWARE
Teste de Caixa-Preta: Métodos

• Partição em Classes de Equivalência
• Método do Grafo de Causa e Efeito

TESTES DE SOFTWARE
Partição em Classes de Equivalência

• Esta metodologia é adequada ao teste de valores típicos de
entrada de um programa.
• Os casos de teste são gerados a partir do conhecimento das

entradas, de maneira sistemática e direta.
• A entrada de dados no programa é dividida em classes que

serão testadas a partir de um caso de uso específico. O objetivo
dessa técnica é eliminar os casos de testes redundante.
• Projeto de casos de teste para particionamento de equivalência é

baseado numa avaliação das classes de equivalência para uma
condição de entrada.
TESTES DE SOFTWARE
Etapas da Técnica
1. Identificar as classes de equivalência de Entrada
2. Refinar as classes de Entrada
3. Identificar as classes de Saída
4. Refinar as Classes de Saída
5. Relacionar as Classes de Entrada e de Saída
6. Definir os casos de teste

TESTES DE SOFTWARE
Método do Grafo de Causa e Efeito

• É uma rede lógica combinatorial que representa a especificação
do programa. É análogo a um circuito lógico digital.
• Para construí-lo procedemos da seguinte forma:

• Identificar as Causas: As causas são as entradas do
programa. Tomar o cuidado de não identificar causas
complementares, como por exemplo "x > 60" e "x <=60".
Colocá-las à esquerda no diagrama.
• Identificar Efeitos: Os efeitos são as saídas do programa.
Colocá-los à direita no diagrama.

TESTES DE SOFTWARE

• Relacionar as causas com os efeitos através da seguinte
notação:

TESTES DE SOFTWARE

• Relacionar as causas com os efeitos através da seguinte
notação:

Teste de Ambiente Web
TESTES DE SOFTWARE
Introdução
• Com o crescimento da Internet e a evolução das tecnologias
envolvidas, as aplicações na WEB também evoluíram.
• Hoje grande parte dos negócios da organizações também estão

na WEB e consequentemente ocorreu um aumento nos números
de aplicações desenvolvidas para este fim.

TESTES DE SOFTWARE
Introdução
• O teste de uma aplicação WebApp (aplicações para Web) é
um conjunto de atividades relacionadas com um único
objetivo:
• Descobrir erros
• Mas como?
• Para atingir este objetivo deve ser utilizada uma estratégia de

teste que abrange as revisões e o teste executável.

TESTES DE SOFTWARE
Introdução
• O processo de teste começa focando os aspectos visíveis da
aplicação ao usuário e abrange os aspectos de tecnologia e
infraestrutura, neste caso em sete etapas de teste:
1. No conteúdo,
2. Na função,
3. Na usabilidade,
4. Na navegabilidade,
5. No desempenho,
6. Na capacidade,
7. Na segurança das aplicações e etc.

TESTES DE SOFTWARE
Introdução
• A qualidade, segundo Pressman (2011) é incorporada a uma
aplicação Web como consequência de um bom projeto.
• “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.

TESTES DE SOFTWARE
Conceito de Teste na Web

• 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.
• A qualidade é avaliada aplicando-se uma série de revisões

técnicas e de um processo de teste com o objetivo de
examinar uma ou mais das seguintes dimensões de
qualidade:

TESTES DE SOFTWARE
Dimensões de Qualidade
Segurança Conteúdo Função
Estrutura
Interoperabilidade Qualidade
Usabilidade
Compatibilidade Desempenho Navegabilidade

TESTES DE SOFTWARE
• Conteúdo: É avaliado no nível semântico e sintático. No
nível sintático examina-se a ortografia, pontuação e
gramática. No nível semântico são verificadas a exatidão,
consistência e ausência de ambiguidade das informações.
• Função: É testada para descobrir erros que indicam falta de

conformidade com os requisitos do cliente.

TESTES DE SOFTWARE
• Estrutura: É avaliada para assegurar o fornecimento
apropriado do conteúdo e função da aplicação. Que seja
extensível e possa ser mantida à medida que novo conteúdo
ou funcionalidade é adicionado
• Usabilidade: é testada para garantir que cada categoria de

usuário seja suportada pela interface.

TESTES DE SOFTWARE
• Navegabilidade: É testada para assegurar que toda a sintaxe
e semântica de navegação sejam experimentadas para
descobrir quaisquer erros de navegação.
• Desempenho: É testado sob uma variedade de condições de

operação, configuração e carga para assegurar que o sistema
responda à interação com o usuário e suporte cargas
extremas sem degradação inaceitável de operação.

TESTES DE SOFTWARE
• Compatibilidade: É testada executando-se a aplicação em
uma variedade de diferentes configurações hospedeiras tanto
no lado cliente quanto no lado servidor.
• Interoperabilidade: É testada para garantir que a aplicação

tenha uma interface adequada com outras aplicações e/ou
bases de dados.

TESTES DE SOFTWARE
• Segurança: É testada para investigar vulnerabilidades
potenciais e tentar explorar cada uma delas. Qualquer
tentativa bem-sucedida de invasão é considerada falha de
segurança.

TESTES DE SOFTWARE
O Processo de Teste na Web

• O processo de teste da aplicação Web começa com testes
que verificam o conteúdo e a funcionalidade da interface.
• Posteriormente são verificados aspectos da arquitetura do

projeto e da navegação da aplicação e finalizando com os
testes que examinam os recursos tecnológicos.
• Diversos deste testes não são aparentes para o usuário final.

TESTES DE SOFTWARE

• Tarefas importantes:
1. Revise os requisitos dos interessados. Identifique metas e

objetivos-chave do usuário. Revise os casos de uso para cada
categoria de usuário.
2. Estabeleça prioridades para garantir que cada meta e objetivo
do usuário seja testado.
3. Defina a estratégia de teste da aplicação descrevendo os tipos
de teste que serão conduzidos.
4. Desenvolva um plano de testes.

TESTES DE SOFTWARE

• Tarefas importantes (cont.):
5. Execute testes de unidade. Revise o conteúdo quanto à erros

sintáticos e semânticos.
6. Realize testes de integração. Conduza testes de navegação.
7. Realize testes de configuração. Avalie a configuração do lado
do cliente e do lado do servidor.
8. Conduza testes de desempenho.
9. Conduza testes de segurança.

TESTES DE SOFTWARE

• Podemos observar melhor o processo de teste na Web
através da figura adiante, representado através de uma
pirâmide, os elementos que são visíveis ao usuário, são
testados em primeiro lugar.
• O fluxo do nosso processo de teste começa da esquerda para

direita e de cima para baixo, começando pelo teste de
conteúdo, teste de interface, teste de navegação, de
componente e finalizando com os testes de configuração,
desempenho e segurança.

TESTES DE SOFTWARE

TESTES DE SOFTWARE

1. O modelo de conteúdo é revisto para descobrir erros;
2. O modelo de interface é revisto para garantir que todos os
casos de uso possam ser acomodados;
3. O modelo de projeto da aplicação é revisto para descobrir
erros de navegação;
4. A interface com o usuário é testada para descobrir erros nos
mecanismos de apresentação e/ou navegação;
5. Os componentes funcionais são submetidos a testes de
unidade;
6. É testada a navegação por toda a arquitetura;

TESTES DE SOFTWARE

7. A aplicação Web é implementada em uma variedade de
configurações ambientais diferentes e testada quanto à
compatibilidade com cada configuração;
8. São executados testes de segurança na tentativa de explorar
vulnerabilidades na Aplicação ou em seu ambiente;
9. São realizados testes de desempenho;
10.A aplicação é testada por uma população de usuários finais
controlados e monitorados e os resultados de suas interações
com o sistema são avaliados quanto a erros de conteúdo e
navegação, usabilidade, compatibilidade, segurança,
confiabilidade e desempenho.

TESTES DE SOFTWARE
Teste de Conteúdo
• O teste de conteúdo tenta descobrir erros antes que sejam
encontrados pelos usuários.
• Ele combina tanto as revisões, já estudadas nas aulas

anteriores, quanto à geração de casos de tese executáveis.
• Os testes de conteúdo têm três importantes objetivos:

1. Descobrir erros de sintaxe;
2. Descobrir erros de semântica
3. Encontrar erros na organização ou estrutura do conteúdo
apresentado ao usuário final;

TESTES DE SOFTWARE
Teste de Conteúdo
• O revisor deverá responder as seguintes perguntas:
• As informações são precisas?
• As informações são concisas e direcionadas ao assunto?
• É fácil para o usuário entender o layout do conteúdo?
• As informações apresentadas são consistentes internamente
e consistentes com as apresentadas em outros objetos?
• Foram fornecidas referências apropriadas para todas as
informações derivadas de outras fontes?

TESTES DE SOFTWARE
Teste de Conteúdo
• O revisor deverá responder as seguintes perguntas:
• O conteúdo é ofensivo, confuso ou dá margem a litígio?
• O conteúdo desrespeita os direitos autorais existentes ou de
marcas registradas?
• O conteúdo contém links que complementam o conteúdo
existente? Os links estão corretos?
• O estilo estético do conteúdo está em conflito com o estilo
estético da interface?

TESTES DE SOFTWARE
Teste de Interface com o Usuário

• A verificação e validação de uma interface de usuário ocorre
em três pontos distintos:
• Durante a análise ➔ Garantir que esteja de acordo com os

requisitos do cliente;
• Durante o projeto ➔ Garantir que critérios genéricos de
qualidade e que tópicos específicos foram tratados;
• Durante o teste ➔ Execução de tópicos específicos relativos
à interação como usuário e fornece uma avaliação final da
usabilidade.

TESTES DE SOFTWARE

• Tem como objetivo descobrir erros relacionados com os
mecanismos específicos da interface e descobrir erros na
maneira como a interface implementa as semânticas de
navegação, as funcionalidades da aplicação ou ainda na
exibição do conteúdo.
• Desta forma podemos distinguir basicamente quatro tipos de

testes:

TESTES DE SOFTWARE

• Testes de mecanismos de interface: Avalia a interação de
cada mecanismos oferecido ao usuário através da interface:
link, formulários, script executado pelo cliente, janelas pop up
e etc.
• Teste de semântica da interface: Avalia como o projeto se

preocupa com os usuários.

TESTES DE SOFTWARE

• Teste de usabilidade: determina o grau com o qual a
interface da aplicação facilita a vida do usuário.
• Teste de compatibilidade: Diferentes computadores,

dispositivos de imagem, sistemas operacionais, navegadores
e velocidades de conexão de rede pode ter influência
significativa na operação da aplicação Web.

TESTES DE SOFTWARE
Teste de Componente
• O teste de componente, também conhecido como teste de
função, tem como objetivo tentar descobrir erros nas funções
da aplicação Web.
• Cada uma destas funções é um componente de software que

pode ser implementados através de diferentes linguagens e
testados através de teste de caixa-preta ou ainda de caixa-
branca, ambos já estudados.

TESTES DE SOFTWARE
Teste de Componente
• Cada caso de teste de componente especifica todos os
valores de entrada e saída esperada a ser fornecida pelo
componente.
• Em muitas situações, a execução correta de uma função da

aplicação está ligada ao interfaceamento correto com um
banco de dados que pode ser externo a aplicação, desta
forma, o teste de banco de dados torna-se parte importante
do teste de componente.

TESTES DE SOFTWARE
Teste de Navegação
• Um usuário navega por uma aplicação WEB de modo muito
semelhante ao que um visitante caminha por uma loja ou
museu.
• Há muitos caminhos que podem ser trilhados, muitas paradas

que podem ser feitas, muitas coisas para aprender e observar,
atividades a iniciar e decisões a tomar.

TESTES DE SOFTWARE
Teste de Navegação
• Seu objetivo é garantir que os mecanismos que permitem ao
usuários navegar através da aplicação Web estejam todos em
funcionamento e que cada unidade semântica de navegação
possa ser alcançada pela categoria apropriada de usuário.
• Desta forma este tipo de teste abrange:

- Sintaxe
- Semântica

TESTES DE SOFTWARE
Teste de Navegação - Sintaxe

• Segundo Pressman, neste tipo de teste os mecanismos de
navegação são verificados para garantir que cada um execute
sua função planejada e garantir que os erros sejam
encontrados antes que a aplicação entre no ar:
• Links de navegação: Cada link deverá ser testado para

assegurar que o conteúdo ou funcionalidade apropriada sejam
alcançados quando o link é escolhido.

TESTES DE SOFTWARE

• Redirecionamentos: Quando um usuário solicita uma URL
não existente ou seleciona um link cujo conteúdo foi removido,
é exibida uma mensagem para o usuário e a navegação é
redirecionada para outra página.
• Marcadores de páginas (Booksmarks): Apesar de ser uma

função do navegador, deverá ser testado para assegurar que
possa ser extraído um título de página com significado quando
o marcador for criado.

TESTES DE SOFTWARE

• Mapas do site: Como o mapa do site fornece uma tabela
completa de conteúdo para todas as páginas da web, cada
entrada deverá ser testada.
• Dispositivos de busca interna: Muitas aplicações, devido a

quantidade de informações existentes, implementam
mecanismos de busca. Deverá ser testado o teste destes
mecanismos para validar a precisão e a totalidade da busca.

TESTES DE SOFTWARE

• Molduras e conjunto de molduras: Cada moldura tem o
conteúdo de uma página web específica. Um conjunto de
moldura permite que várias páginas sejam exibidas ao mesmo
tempo. O conjunto de molduras deverá ser testado quanto ao
correto conteúdo, layout, dimensionamento apropriados e
quanto a compatibilidade com o navegador.

TESTES DE SOFTWARE
Teste de Navegação - Semântica

• A unidade semântica de navegação (NSU) pode ser
exemplificada por um conjunto de caminhos de navegação
que conectam nós de navegação (por exemplo, páginas Web,
objetos de conteúdo ou funcionalidade) que permite ao
usuário satisfazer requisitos específico definidos por um ou
mais casos de uso para uma categoria de usuário.

TESTES DE SOFTWARE

• Neste caso o teste semântico deverá responder as
seguintes perguntas:
• A NSU é atendida sem erro?

• Cada nó de navegação é acessível no contexto dos caminhos
de navegação definidos para a NSU?
• Todos os caminhos relevantes foram testados?
• Se forem fornecidas instruções pela interface de usuário para
ajudar na navegação as instruções são corretas e inteligíveis
à medida que a navegação ocorre?

TESTES DE SOFTWARE

• Neste caso o teste semântico deverá responder as
seguintes perguntas:
• Existe algum mecanismo para voltar a um nó de navegação

anterior e ao início do caminho de navegação?
• Se uma função é executada em um nó e ocorre um erro no
processamento da função, a NSU pode ser completada?
• Todos os nós podem ser acessados do mapa do site? Os
nomes dos nós têm significado para os usuários finais?

TESTES DE SOFTWARE

• O teste de navegação, bem com o teste de interface e de
usabilidade, devem ser feitos além dos testadores, também
por diferentes clientes, sempre que possível!

TESTES DE SOFTWARE
Teste de Configuração
• O objetivo do teste de configuração (Pressman, 2011) é testar
um conjunto de prováveis configurações do cliente e do
servidor para assegurar que a experiência do usuário será a
mesma em todos os casos e isolar erros que podem ser
específico a uma determinada configuração.

TESTES DE SOFTWARE
• Lado Servidor: Os casos de teste são projetados para
verificar se a configuração do servidor pode suportar a
aplicação sem erro.

TESTES DE SOFTWARE
• Perguntas a serem respondidas:
• A aplicação é totalmente compatível com o sistema operacional do
servidor?
• Os arquivos de sistema, diretórios e dados de sistema relacionados

são criados corretamente quando a aplicação está operacional?
• As medidas de segurança permitem que a aplicação seja executada

sem a interferência ou degradação do desempenho?
• A aplicação está adequadamente integrada com o software de banco

de dados?
• Os scripts utilizados pela aplicação executam corretamente?

TESTES DE SOFTWARE
• Lado Cliente: Foca a compatibilidade da aplicação com
configurações dos seguintes componentes:
• Hardware: CPU, memória, armazenamento e dispositivo de

impressão;
• Sistemas operacionais: Linux, Macintosh OS, Microsoft, S.O.
Móvel.
• Software Navegador: Firefox, Safari, Internet Explorer, Opera,
Chrome e outros.
• Componentes de interface de usuário: Active X, java Applets
e outros.
• Plug-ins: QuickTime, RealPlayer e outros.
• Conectividade: Cabo, DSL, modem , WIFI.
TESTES DE SOFTWARE
Estes testes devem ser projetados onde cada categoria
de usuário seja avaliada para determinar as prováveis
configurações que serão encontradas, reduzindo assim o
número de variáveis de configuração para um número
gerenciável.

TESTES DE SOFTWARE
Teste de Segurança
• As aplicações Web e os ambientes cliente e servidor nos
quais as aplicações estão alojadas representam um alvo para
invasores externos, funcionários insatisfeitos, concorrentes
desonestos e qualquer outro que queira roubar informações
sigilosas, modificar conteúdo maliciosamente, degradar o
desempenho ou desabilitar funcionalidades.

TESTES DE SOFTWARE
Teste de Segurança
• Estes testes são projetados para investigar
vulnerabilidades:
• No ambiente do lado do cliente;
• Na comunicação de rede que ocorrem quando os dados são

passados do cliente para o servidor;
• Na comunicação de rede que ocorrem quando os dados são

passados do servidor para o cliente;
• No ambiente do lado servidor.

TESTES DE SOFTWARE
Teste de Desempenho
• A medida que em que aumenta o número de usuários nas
aplicações web, consequentemente ocorre um aumento do
número de transações online ou na quantidade de dados
através das operações de download ou upload.
• É muito frustrante para um usuário quando uma aplicação

leva muitos minutos para carregar o conteúdo ou quando ao
recebe do servidor uma mensagem do tipo “servidor
ocupado”.

TESTES DE SOFTWARE
Teste de Desempenho
• O teste de desempenho é usado para descobrir problemas de
desempenho que podem resultar, por exemplo, da falta de
recursos no lado do servidor, da largura da banda ou recursos
de banco de dados inadequados.
• A intenção é entender como os sistemas respondem quando a

carga aumenta e ainda reunir métricas que conduzirão a
modificações de projeto para melhorar o desempenho.

TESTES DE SOFTWARE
Teste de Desempenho
• Este tipo de teste ajudará a responder as seguintes
questões:
• O tempo de resposta do servidor degrada de forma a
tornar-se inaceitável?
• Em que ponto, sob o ponto de vista dos usuários,
transações ou cargas de dados, o desempenho se torna
inaceitável?
• Quais componentes do sistema são responsáveis pela
degradação do desempenho?
• Qual o tempo médio de resposta para usuários sob
diferentes condições de carga?

TESTES DE SOFTWARE
Teste de Desempenho
• Para obter respostas a essas perguntas são feios dois testes
diferentes de desempenho:
- Teste de carga
- Teste de esforço (Stress)

TESTES DE SOFTWARE
Teste de Desempenho
• Teste de Carga: A finalidade do teste de carga é determinar
como a webApp e seu ambiente do lado do servidor
responderá a várias condições de carga. São utilizadas como
condições de teste as seguintes variáveis:
• Número de usuários concorrentes (N)

• Número de transações on-line por usuários por unidade de
tempo (T)
• Carga de dados processados pelo servidor por transação
(D)

TESTES DE SOFTWARE
Teste de Desempenho
• À medida que o teste é feito, são realizadas permutações nas
variáveis de acordo com os limites de operação normal do
sistema e coletas uma ou mais das seguintes medidas:
• Resposta média do usuário;

• Tempo médio para o download de uma unidade
padronizada de dados;
• Tempo médio para processar uma transação;

TESTES DE SOFTWARE
Teste de Desempenho
• Teste de Esforço (stress): É uma continuação do teste de
carga, e desta forma utilizam as mesmas variáveis: T, N, D,
porém com seus limites operacionais excedidos.

TESTES DE SOFTWARE
Teste de Desempenho
• A finalidade deste teste é responder as seguintes questões:
• O sistema degrada ou o servidor desliga quando é excedida a

capacidade normal de operação?
• O software servidor gera mensagens “servidor não disponível”?

De uma maneira geral os usuários ficam cientes de que não
podem acessar o servidor?
• O servidor coloca as requisições por recursos em fila e esvazia

a fila quando a demanda de capacidade diminui?
• São perdidas transações quando a capacidade é excedida?

TESTES DE SOFTWARE
Teste de Desempenho
• A finalidade deste teste é responder as seguintes questões:
• A integridade dos dados é afetada quando a capacidade é

excedida?
• Quais valores de N, T e D forçam o ambiente servidor a

falhar? Como a falha se manifesta? São mandadas
notificações automáticas para o pessoal de suporte técnico
no local do servidor?
• Se o sistema falha, quanto tempo demora até que volte a

ficar on-line?

Testes Soft Und 03

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Testes Soft Und 03

Загружено:

Авторское право:

Доступные форматы

TESTES DE SOFTWARE

Unidade 3 – Teste no Programa

Unidade 3 – Teste no Programa

Unidade 3 – Teste no Programa

• Geralmente era vista com o um castigo para o programador,

• O tema esteve relegado a segundo plano, e, até alguns anos

Unidade 3 – Teste no Programa

• As técnicas que vamos estudar auxiliam principalmente na

• Deve-se deixar claro que testar não é a única maneira de se

• As técnicas do tipo "walkthroughs" (revisões estruturadas)

Unidade 3 – Teste no Programa

• Objetivos do Teste: Mostrar que o software tem erros.

• Objetivos da Depuração (Debug): Encontrar a causa do

Unidade 3 – Teste no Programa

• Em linguagens de baixo nível, erros de código podem causar

Unidade 3 – Teste no Programa

Unidade 3 – Teste no Programa

Unidade 3 – Teste no Programa

Unidade 3 – Teste no Programa

• Nesta metodologia os casos de teste são gerados tendo-se

• É executado na fase de implementação do software

Unidade 3 – Teste no Programa

– Método dos Caminhos Básicos.

Unidade 3 – Teste no Programa

Cobertura Lógica (Critérios Myers)

• Os critérios vão se tornando cada vez mais abrangentes e

– até o mais complexo, eficiente e rigoroso (Cobertura de Múltiplas

Unidade 3 – Teste no Programa

Cobertura Lógica (Critérios Myers)

– Estrutura do programa a ser testado;

– Criticidade do programa a testar;

– Nível de confiança que se deseja atingir.

Unidade 3 – Teste no Programa

Complexidade do programa a testar

• Muitas vezes a utilização de critérios mais rigorosos em

Unidade 3 – Teste no Programa

Estrutura do programa a ser testado

• Ex: Programas ricos em comandos, podem ser testados

Unidade 3 – Teste no Programa

Criticidade do programa a testar

Unidade 3 – Teste no Programa

Nível de confiança que se deseja atingir

Unidade 3 – Teste no Programa

Unidade 3 – Teste no Programa

• Ex: Analisar o fluxograma da figura a seguir

Unidade 3 – Teste no Programa

Unidade 3 – Teste no Programa

• O critério é satisfeito, porém, podemos verificar que mesmo para

• O caso de teste não detectaria, pois o fluxo do programa continuaria

Unidade 3 – Teste no Programa

• No exemplo do fluxograma, dois casos de teste são suficientes para

• Os erros exemplificados no critério anterior seriam detectados.

Unidade 3 – Teste no Programa

• No fluxograma temos as seguintes condições:

• Temos que gerar casos de teste para testar as situações :

Unidade 3 – Teste no Programa

• Observe que com este critério conseguiríamos detectar o erro

• Porém ocorre que nem todas as saídas das decisões são

Unidade 3 – Teste no Programa

• Ainda para o fluxograma da fig. 1 temos que os seguintes

Unidade 3 – Teste no Programa

Cobertura de Múltiplas Condições

• Combinações de condições a serem cobertas:

• Os casos de teste que cobrem estas combinações são:

• No exemplo da figura temos: 