Você está na página 1de 166

1 - Defina testes de software?

A atividade de teste de software um elemento crtico da garantida de


qualidade de software e representa a ultima reviso de especificao, projeto e
codificao.
Segundo Pressman, o teste de software um conjunto de atividades que
podem ser planejadas com antecedncia e executadas sistematicamente.

2 - Quais so os tipos de testes existentes para validao de um


software.
Verificao / Testes Unitrios / Testes de integrao / Teste de sistema / Teste
de aceitao

3 - O que RTF?
Uma RTF uma atividade de garantia de qualidade de software executada por
engenheiros de software e outros profissionais.
4 - Para que serve a RTF?
Descobrir erros na funo, lgica ou implementao
Verificar se o software atende aos requisitos
Garantir que o software foi representado de acordo com os padres
Obter um software que seja desenvolvido uniformemente
Tornar os projetos mais gerenciveis

5 - Em que estgio utilizado o teste unitrio e por quem?


So realizados no estgio mais baixo da escala de teste, normalmente feito
pelos desenvolvedores.

6 - Explique para que serve teste de integrao.


So executados em uma combinao de componentes para verificar se ele
funcionam corretamente juntos, conforme as especificaes.

7 - Qual o objetivo do teste de sistema?

So realizados pela equipe de testes, visando a execuo do sistema como um


todo ou um subsistema (parte de um sistema), dentro de um ambiente
operacional controlado, para validar a exatido e perfeio na execuo de
suas funes.

8 - Explique o modelo de hipoteses validao utilizado na depurao


de um software
O modelo define a atividade de depurao como um processo interativo de
sntese, verificao e refinamento de hiptese.

9 - Quais so os tipos de testes de caixa branca?


Teste de Caminho Bsico
Teste de Condio
Teste de Fluxo de Dados
Teste de Ciclo
Teste de caixa branca uma abordagem de projeto de casos de teste que usa
a estrutura de controle do projeto procedimental para derivar casos de teste.
Baseia-se num minucioso exame dos detalhes procedimentais.

10 - Qual teste utilizado para responder a seguinte questo: Como a


validade funcional testada?
Teste de Caixa Preta

11 - Explique teste de caixa preta. (Anlise do Valor Limite)


uma tcnica que complementa o particionamento de equivalncia: em vez de
selecionar qualquer elemento de uma classe de equivalncia, a BVA leva
seleo de casos de teste nas extremidades da classe.

12 - Quais dimenses devem ser verificadas em um sistema web?


Contedo / Funo / Estrutura / Usabilidade / Navegabilidade / Desempenho /
Compatibilidade / Interoperabilidade / Segurana

13 - Explique o que deve ser verificado em relao dimenso


contedo.
avaliado no nvel semntico e sinttico. No nvel sinttico examina-se a
ortografia, pontuao e gramtica.

14 - Qual dimenso determina o grau com o qual a interface da


aplicao facilita a vida do usurio.
Usabilidade: testada para garantir que cada categoria de usurio seja
suportada pela interface.

15 - Explique porque a curva idealizada no corresponde a real para


verificao de falhas tendo em vista o fator tempo.
Com novas mudanas podem ocorrer novos erros e corrigir esses erros
causar ainda mais gasto de tempo.3

16 - Erros de interface podem ser capturados utilizando-se qual


tcnica de testes?
Teste Caixa Preta

17 - Explique porque devemos verificar no teste de condio? Diga a qual


tcnica ela pertence.

Pe prova as condies lgicas contidas em um mdulo de programa. Teste


Caixa Branca.

18 - Explique o que e Kick-off? Isso componente de qual processo de


teste.
Distribuir os documentos, explicar os objetivos, processos e documentos para
os participantes; e checar os critrios de entrada (para os diversos tipos de
reviso). Componente do RTF

TESTES DE SOFTWARE AULA 1

Rio de Janeiro, 20 de agosto de 2011

CONTEDO
Unidade 1 Importncia do teste de software
O teste nas fases de desenvolvimento de um software.
O teste na engenharia de sistemas e de programas

Unidade 2 - Teste no projeto de sistema


Revises Tcnicas Formais
Validao pelo usurio

CONTEDO
Unidade 3 Teste no programa
Depurao
Teste de caixa branca

Teste de caixa preta


Teste de ambiente Web

CONTEDO
Unidade 4 Teste na implantao do sistema
Teste de Unidade
Teste de Integrao

Teste de Validao
Teste de Sistema
Teste na Migrao

CONTEDO
Unidade 5 Teste de software em sistema em produo
Teste de software nos diversos tipos de manuteno
Confiabilidade

Disponibilidade
Unidade 6 Ferramentas de teste de software
Ferramentas de teste no desenvolvimento de sistema
Ferramentas de teste para o programa
Ferramentas de teste para o ambiente Web

Ferramentas de teste para sistemas em produo


5

A IMPORTNCIA DO TESTE

O desenvolvimento de sistemas envolve uma srie de


atividades em que as oportunidades de injeo de falhas
so muito grandes. Estes erros podem comear a aparecer

logo no incio do processo, onde os objetivos podem estar


erroneamente especificados, alm de erros que venham a
ocorrer em fases de projeto e desenvolvimento posteriores.

A IMPORTNCIA DO TESTE

Por causa da inabilidade humana de realizar e de se


comunicar

com

perfeio,

desenvolvimento

acompanhado de garantia de qualidade.


A atividade de teste de software um elemento crtico da
garantia de qualidade de software e representa a ltima

reviso de especificao, projeto e codificao.

CUSTO DO REPARO

Custo

Requisitos

Codificao

Entrega

Estgio de
desenvolvimento

A IMPORTNCIA DO TESTE

No raro gastarmos entre 30 e 40% do esforo total do


projeto no Teste de Software.
O Teste de Software para ambientes crticos (ex.: controle
de voo, monitoramento de reatores nucleares e etc.) pode
custar de trs a cinco vezes mais do que todos os outros

passos de engenharia de software combinados.

mudana

curva real

ndice de
falhas

curva idealizada

tempo

10

DEFININDO O TESTE DE SOFTWARE


Avaliar se o software est fazendo o que deveria fazer,
de acordo com os seu requisitos, e no est fazendo o que
no deveria fazer;

Qualquer atividade que, a partir da avaliao de um


atributo ou capacidade de um programa ou sistema, seja
possvel

determinar

se

ele

alcana

os

resultados

desejados. (Bill Hetzel 1988).


Processo de executar um programa ou sistema com a
inteno de encontrar defeitos (Glen Myers 1979);
11

DEFININDO O TESTE DE SOFTWARE


Segundo Pressman, o teste de software um conjunto de
atividades que podem ser planejadas com antecedncia e
executadas sistematicamente.

Uma estratgia de teste de software deve acomodar testes


de baixo nvel, necessrios para verificar se um pequeno
segmento de cdigo fonte foi implementado corretamente,
bem como testes de alto nvel, que validam as funes
principais do sistema de acordo com os requisitos do cliente.
12

DEFININDO O TESTE DE SOFTWARE


A atividade de teste um passo do processo de Engenharia
de Software que visa encontrar/corrigir erros ao longo do
software que foi construdo.

Testes podem ser usados para descobrir a presena de


erros, mas no para mostrar a sua ausncia.

Testes de software o processo de executar o software de


uma maneira controlada com o objetivo de descobrir diferenas entre o comportamento previsto e o comportamento

observado.
13

ESTRATGIAS DE TESTE
Todas estratgias fornecem um modelo para o teste e tm
basicamente as seguintes caractersticas:

Para executar um teste eficaz, proceder a revises

tcnicas eficazes. Fazendo isso, muitos erros sero


eliminados antes do comeo do teste.
O teste comea no nvel do componente e progride em
direo integrao do sistema computacional como um
todo.

14

ESTRATGIAS DE TESTE
Todas estratgias fornecem um modelo para o teste e tm
basicamente as seguintes caractersticas:

Diferentes tcnicas de teste so apropriadas para

diferentes abordagens de engenharia de software e em


diferentes momentos
O teste feito pelo desenvolvedor do software e (para
grandes projetos) por um grupo independente de teste.

O teste e a depurao so atividades diferentes, mas

a depurao ocorre em consequncia de um teste.


15

ESTRATGIAS DE TESTE
A atividade de teste o processo de executar um programa
com a inteno de descobrir um erro.

Um bom caso de teste aquele que possui uma elevada


probabilidade de revelar um erro ainda no descoberto.

Um teste bem-sucedido aquele que revela um erro ainda


no descoberto.

16

DIRETRIZES PARA O TESTE


Determinar quando o teste deve ser interrompido.
Atribuir a responsabilidade do teste a um testador.
Descrever os resultados esperados para cada caso de

teste.
Escrever casos de teste para condies de entrada
vlidas e invlidas.
Inspecionar o resultado de cada teste por completo.
Alocar os programadores mais criativos para teste.

17

O PROCESSO DE TESTE
O processo de teste de software deve basear-se em uma
metodologia aderente ao processo de desenvolvimento,
com pessoal tcnico qualificado, ambiente e ferramentas

adequadas.
Esta metodologia de teste deve ser o documento bsico
para organizar a atividade de testar aplicaes no contexto
da empresa. Assim como o processo de desenvolvimento de
software, teste de software tambm possui um ciclo de vida:

18

O PROCESSO DE TESTE

Planejamento

Procedimentos
Iniciais

Especificao

Execuo

Preparao

19

Entrega

O PROCESSO DE TESTE
Planejamento: Elaborao e reviso da Estratgia de teste
e do plano de teste;

Preparao: Preparao do ambiente de teste, incluindo


equipamentos, rede, pessoal, software e ferramentas.

20

O PROCESSO DE TESTE
Procedimentos iniciais: Consiste na elaborao de
documento com o estabelecimento de um acordo entre as
partes envolvidas no projeto de teste (usurios e tcnicos):

21

Objetivo do projeto de teste,

Pessoal a ser envolvido,

As responsabilidades de cada um;

O plano preliminar de trabalho;

Avaliao dos riscos;

Os nveis de servios acordados e etc.

O PROCESSO DE TESTE
Especificao: Elaborao e reviso dos casos de teste ,
scripts ( no caso de ferramentas de automao de testes)
e dos roteiros de Teste e execuo dos testes de verificao

da documentao do sistema (testes estticos).


Execuo: Execuo dos testes planejados conforme os
Casos de Teste, scripts e dos roteiros de Teste com os
correspondentes registros dos resultados obtidos.
Entrega: concluso do processo de testes com a entrega
do sistema para o ambiente de produo.
22

INTERAO ENTRE OS CICLOS DE VIDA

23

O PROCESSO DE TESTE
H muitas estratgias que podem ser utilizadas para testar
um software. Uma das estratgias de teste que preferida
pela maioria das equipes a viso incremental do teste,
comeando com o teste das unidades individuais de

programa, passando para os testes destinados a facilitar a


integrao de unidades e culminando com testes que usam
o sistema concludo.
Verificao: Nesta etapa so realizadas inspees/revises
sobre os produtos gerados.
24

O PROCESSO DE TESTE
Testes Unitrios: So realizados no estgio mais baixo da
escala de testes e so aplicados nas menores componentes
de cdigos criados, visando garantir que estes atendem as

especificaes, em termos de garantia e de funcionalidade.


Verificam o funcionamento de um pedao do sistema ou
software

isoladamente

ou

que

possam

separadamente.

Normalmente feito pelos desenvolvedores.


25

ser

testado

O PROCESSO DE TESTE
Testes

de

integrao:

So

executados

em

uma

combinao de componentes para verificar se ele funcionam


corretamente

juntos,

conforme

as

especificaes.

Componentes podem ser pedaos de cdigo, mdulos,


aplicaes distintas, clientes servidores. Normalmente
feito pelos desenvolvedores.

26

O PROCESSO DE TESTE
Teste de sistema: So realizados pela equipe de testes,
visando a execuo do sistema como um todo ou um
subsistema (parte de um sistema), dentro de um ambiente

operacional controlado, para validar a exatido e perfeio


na execuo de suas funes. Neste estgio de teste deve
ser simulada a operao normal do sistema, sendo testadas
todas as suas funes de forma mais prxima possvel do
que ir ocorrer no ambiente de produo. Esses testes so
feitos pela equipe de teste de software.
27

O PROCESSO DE TESTE
Teste de aceitao: So os testes finais de execuo do
sistema, realizados pelos usurios, visando verificar se a
soluo atende aos objetivos

requisitos,

no

que

diz

do negcio e aos seus

respeito

funcionalidade

usabilidade, antes da sua utilizao no ambinete de


produo.

28

O PROCESSO DE TESTE
Ao tratar os testes como um processo organizado e muitas
vezes paralelo e integrado ao processo de desenvolvimento,
os custos de manuteno sero reduzidos. Segundo Myers,

o custo de correo de defeitos tende a aumentar quanto


mais tarde o defeito detectado. Defeitos encontrados
durante a produo tendem a custar muito mais que defeitos
encontrados em modelos de dados e em outros documentos
do projeto do software.

29

O PROCESSO DE TESTE
Os testes unitrios podem remover entre 30% e 50 %
dos defeitos dos programas;

Os testes de sistemas podem remover entre 30% e

50% dos defeitos remanescentes.

Desse modo, os sistemas podem ir para produo

ainda com aproximadamente 49% de defeitos.

Por ltimos, as revises de cdigos podem reduzir entre

20% e 30% desses defeitos.


30

TESTES DE SOFTWARE AULA 2

Rio de Janeiro, 21 de agosto de 2011

TESTE NO PROJETO DE SISTEMAS


E TESTE NO PROGRAMA
DEPURAO

OBJETIVOS DESTA AULA


1. Compreender a necessidade de testes na especificao
do projeto;
2. Aprender como planejar e aplicar testes no projeto de

software;
3. Compreender e identificar a origem e a causa do erro;
4. Compreender e implementar tcnicas e estratgias
para identificao do erro.

INTRODUO
medida que o trabalho da engenharia de software
desenvolvido, normal que ocorram erros. importante
que estes erros sejam encontrados e corrigidos antes que

sejam passados para os usurios finais.


Um dos mtodos utilizados para a deteco destes erros

logo no incio do processo de desenvolvimento de software


so as revises de software. Elas so aplicadas em vrias
etapas durante o processo de engenharia de software e

servem para revelar erros que podem ser eliminados.


4

INTRODUO
Lembre-se: Errar humano e, embora algumas pessoas
captem bem alguns de seus erros, outros tantos escapam
mais facilmente a quem lhe deu origem do que a outras

pessoas.
Uma reviso genericamente falando, uma forma de usar
a diversidade de um grupo de pessoas para:

INTRODUO
Apontar aperfeioamentos necessrios no produto de
uma nica pessoa ou de uma equipe.
Confirmar aquelas partes de um produto em que
aperfeioamentos so indispensveis ou desnecessrios.
Obter trabalho tcnico de qualidade mais uniforme, ou

pelo menos mais previsvel, que possa ser alcanada sem


revises, de modo a tornar o trabalho tcnico mais
gerencivel.
6

INTRODUO
Diferentemente da reviso de software, A depurao de
software

comumente

definida

como

tarefa

de

localizao e remoo de defeitos. Ela ocorre como

consequncia de um teste bem sucedido, ou seja, ela


ocorre sempre que um defeito revelado.

importante observar que defeitos podem ser revelados


em diferentes fases do ciclo de vida do software e a
depurao possui caractersticas diferentes, dependendo
da fase em que se encontra o software.
7

INTRODUO
A depurao durante a codificao um atividade
complementar de codificao.
J a depurao depois do teste ativada pelo teste
bem-sucedido, isto , revela a presena de defeitos.
A depurao durante a manuteno ocorre pode

necessidade de manuteno no software, que pode ter


sido causada, por um defeito revelado depois de liberado
o software ou pela necessidade de acrescentar novas
caractersticas.
8

REVISES TCNICAS
So utilizadas logo no incio do processo de Gesto de
Qualidade.

Por que so importantes?

Ao se descobrir um erro logo no incio do processo, fica

menos caro corrig-lo. Temos que levar em considerao


tambm que os erros podem aumentar medida que o
processo continua.
9

REVISES TCNICAS
Por que so importantes? (cont.)

Um erro relativamente insignificante, sem tratamento

no incio do processo, pode ser ampliado e se transformar


em um conjunto de erros graves para a sequncia do
projeto.

Minimizam o tempo devido reduo do nmero de

reformulaes que sero necessrias ao longo do projeto.


10

REVISES TCNICAS
Impacto dos defeitos de software nos custos
Muitas vezes o termo erro utilizado para indicar um
problema de qualidade que descoberto antes do software
ser liberado ao usurio final.
Utilizamos a revises tcnicas para encontrar erros

durante o processo de desenvolvimento, de modo a no se


tornarem defeitos depois da liberao do software.

descoberta precoce de erros, evita que sejam propagados


para a prxima etapa na gesto da qualidade.
11

REVISES TCNICAS
Impacto dos defeitos de software nos custos
Segundo Pressman, diversos estudos e anlise sobre o
tema indicam que a atividades de projeto introduzem de 50
a 60% de todos os erros, durante a gesto da qualidade.
Entretanto, tcnicas de reviso demonstraram ser at 75%

eficazes na descoberta de falhas no projeto.

12

REVISES TCNICAS
Impacto dos defeitos de software nos custos
O benefcio das revises a descoberta precoce dos
defeitos de software, de forma que possam ser corrigidos
antes do passo seguinte.
Ao detectar e suprimir estes erros, o processo de reviso

reduz substancialmente o custo dos passos subsequentes.

13

REVISES TCNICAS FORMAIS (RTF)


A formalidade do processo de reviso relacionada a
fatores

como

maturidade

do

processo

de

desenvolvimento, requisitos legais e reguladores ou a

necessidade de acompanhamento de auditoria.

O modo como uma reviso conduzida depende do seu


objetivo

(ex:

encontrar

defeitos,

obter

compreenso,

auditoria, discusso ou decises por um consenso).

14

REVISES TCNICAS FORMAIS (RTF)


Uma RTF uma atividade de garantia de qualidade de
software executada por engenheiros de software e outros
profissionais.

Cada RTF realizada como um encontro e somente ser


bem

sucedida

se

for

controlada e assessorada.

15

adequadamente

planejada,

REVISES TCNICAS FORMAIS (RTF)


Objetivos:
Descobrir erros na funo, lgica ou implementao
Verificar se o software atende aos requisitos
Garantir que o software foi representado de acordo com
os padres

Obter um software que seja desenvolvido uniformemente


Tornar os projetos mais gerenciveis

16

REVISES TCNICAS FORMAIS (RTF)


Fases principais:
Planejamento Selecionar a equipe, alocar as funes,
definir os critrios de entrada e de sada para os diversos
tipos de reviso formal (ex: inspeo), e selecionar quais as
partes dos documentos sero vistos.
Kick-off Distribuir os documentos, explicar os objetivos,
processos e documentos para os participantes; e checar os

critrios de entrada (para os diversos tipos de reviso).


17

REVISES TCNICAS FORMAIS (RTF)


Fases principais (cont.):
Preparao individual trabalho feito antecipadamente
por cada participante da reunio de reviso, tomando nota
dos defeitos em potenciais, questes e comentrios.
Reunio de reviso

18

REVISES TCNICAS FORMAIS (RTF)


Fases principais (cont.):
Retrabalho

Resolver defeitos encontrados. Atividade

tipicamente realizada pelo autor.


Acompanhamento

Checar se os defeitos foram

encaminhados, obtendo mtricas e checando o critrio de

sada (para certos tipos de revises formais).

19

REVISES TCNICAS FORMAIS (RTF)


Restries:
Entre 3 e 5 pessoas;
Uma preparao antecipada deve ocorrer, mas ela no

deve exigir mais de 2h de cada pessoa;


A durao da reunio deve ser inferior a 2h.

Uma RTF concentra-se numa parte especfica e pequena


do software, pois ao estreitar o foco, tem-se a probabilidade

maior de revelar erros.


20

REVISES TCNICAS FORMAIS (RTF)


Tipicamente uma reunio programada para o dia seguinte
ao da preparao, e conta com o produtor e os revisores.
Durante a RTF, um revisor registra ativamente todos os

problemas levantados. Estes so sintetizados no final da


reunio de reviso e produzida uma lista de problemas
de reviso, alm do relatrio sintetizado da reviso
tcnica formal. Normalmente o relatrio sintetizado um
formulrio de uma pgina, cujo anexo a lista de

problemas de reviso.
21

REVISES TCNICAS FORMAIS (RTF)


Ao final, os participantes devem decidir se:
1. Aceitam o produto sem modificaes adicionais;

2. Rejeitam o produto devido a erros graves (uma vez


corrigidos, outra reviso deve ser realizada);
3. Aceitam o produto provisoriamente (erros menores

foram encontrados e devem ser corrigidos, sem reviso


adicional).

22

TESTE NO PROGRAMA - DEPURAO

23

TESTE NO PROGRAMA - DEPURAO


O processo de depurao frequentemente ocorre em
consequncia de um teste. Quando um caso de teste
descobre um erro, a depurao ser o processo que ir

resultar na remoo deste erro.


O Processo de depurao tenta combinar o sintoma com a

causa, levando assim correo do erro. Normalmente


apresentar um dentre dois resultados:
A causa ser encontrada e corrigida;
A causa no ser encontrada;
24

ABORDAGENS DA DEPURAO
Independente da abordagem adotada, a depurao tem um
objetivo primordial, que encontrar e corrigir a causa de
erro ou defeito.

Um dos modelos existentes o modelo genrico de


depurao chamado de Hipteses-Validao. O modelo
define a atividade de depurao como um processo
interativo de sntese, verificao e refinamento de hiptese.

25

ABORDAGENS DA DEPURAO

Inicie conjunto de hipteses


O responsvel pela depurao
estabelece
hipteses
com
relao localizao do defeito e
modificao para corrigi-lo.

Modifique conjunto de hipteses

O processo de depurao
guiado pela certificao/refutao
das hipteses levantadas, bem
como pela gerao de novas
hipteses e refinamentos das j
existentes.

Selecione hiptese

Verifique hiptese

Sim
26

Corrigido?

No

ABORDAGENS DA DEPURAO
Segundo Pressman, o objetivo da depurao alcanado
por uma combinao de avaliao sistemtica, intuio e
sorte, sendo definido basicamente trs estratgias (Myers):

1. Fora bruta
2. Rastreamento (backtracking)
3. Eliminao da causa

27

ABORDAGENS DA DEPURAO
Fora bruta
Mtodo mais comum e menos eficiente;

Usado quando os outros mtodos falham;


Faz-se

imensa

planejamento.

28

quantidade

de

teste,

mas

sem

ABORDAGENS DA DEPURAO
Rastreamento (backtracking)
A partir do local do sintoma descoberto, rastreia-se para

trs at encontrar a causa;


Bastante
pequenos,

comum,
pois

porm

nmero

restrita
de

caminhos

programas
retroativos

potenciais pode ser muito alto;


Em sistemas/programas mdios/grandes ineficiente;

29

ABORDAGENS DA DEPURAO
Eliminao da causa
Os dados relacionados ocorrncia de erros so

organizados para isolar causas em potencial;


Uma hiptese de causa imaginada e dados acima
so usados para provar ou reprovar a hiptese;
Uma lista de todas as causas possveis desenvolvida
e testes so realizados para eliminar cada uma.

30

CONSIDERAES PSICOLGICAS
Efetuar testes e depurao um trao humano inato;
Certas pessoas so boas para fazer isso, outras no;
A depurao uma das partes mais frustrantes da

programao. Ela indica o reconhecimento de que erramos;


A elevada ansiedade, a presso, o tempo curto, a
pouca disposio para aceitar a possibilidade de erro,
aumenta a dificuldade da tarefa;
Quando um erro enfim corrigido, vem um grande

suspiro de alvio e uma diminuio da tenso.


31

CORREO DO ERRO
Segundo Pressman, uma vez encontrado o erro, ele precisa
ser corrigido. A correo de um defeito pode introduzir
outros erros e, portanto, causar mais danos do que trazer

benefcios.

Segundo Van Vleck, trs perguntas devem ser feitas antes


de fazer a correo que remove a causa de um defeito:

32

CORREO DO ERRO
Questionamentos de Van Vlek:

1. A causa do defeito reproduzida em outra parte do

programa?
Em muitas situaes, o defeito provocado por um
padro de lgica errneo que pode ser reproduzido em
outro lugar.

33

CORREO DO ERRO
Questionamentos de Van Vlek:

2. Qual o prximo defeito que poderia ser introduzido

pelo reparo que estou prestes a fazer?


Se a correo tiver de ser feita em um mdulo com
alto acoplamento, deve-se tomar um cuidado especial.

34

CORREO DO ERRO
Questionamentos de Van Vlek:

3. O que poderamos ter feito para eliminar este defeito

j no incio?
Se corrigirmos o processo, bem como o produto,
o defeito pode ser eliminado de todos os programa
futuros.

35

PISTAS PARA A DEPURAO


O sintoma e a causa podem estar geograficamente distantes;
O sintoma pode desaparecer quando outro erro corrigido;
O sintoma pode ser causado por no erro (ex: arredonda);

O sintoma pode ser causado por um erro humano;


O sintoma pode ser causado por problema de sincronizao;
Pode ser difcil reproduzir com preciso as condies que
originam o erro;
O sintoma poder ser intermitente.
O sintoma pode ocorrer devido as causas distribudas por
vrias tarefas, executando em diferentes processadores.
36

TESTES DE SOFTWARE AULA 3

Rio de Janeiro, 21 de agosto de 2011

TESTE NO PROGRAMA
TESTE CAIXA BRANCA E
TESTE CAIXA PRETA

OBJETIVOS DESTA AULA


1. Compreender os testes de interior do programa;
2. Definir testes para o interior do programa;
3. Implementar testes para o interior do programa;

4. Avaliar testes realizados no interior do programa.

INTRODUO

Uma vez gerado o cdigo-fonte, o software deve ser

testado para descobrir (e corrigir) tantos erros quanto


possvel antes de fornec-lo ao cliente.
O objetivo do teste encontrar erros, e um bom teste
aquele que tem alta probabilidade de encontrar um erro.

Devem ter uma serie de caractersticas que permitam


atingir o objetivo de encontrar o maior nmero de erros com
o mnimo de esforos.
4

INTRODUO
Testes podem ser usados para descobrir a presena de
erros, mas no para mostrar a sua ausncia.
Testes de software o processo de executar o software
de uma maneira controlada com o objetivo de descobrir
diferenas

entre

comportamento

previsto

comportamento observado.
Um teste bem-sucedido aquele que revela um erro
ainda no descoberto.
5

INTRODUO

Devemos projetar testes que tenham a mais alta

probabilidade de descobrir a maioria dos erros com uma


quantidade mnima de tempo e esforo;
Os mtodos de projeto de casos de teste oferecem ao
desenvolvedor uma abordagem sistemtica ao teste.

Oferecem ainda um mecanismo que ajuda a garantir a


integridade do teste e proporciona a mais alta probabilidade
de revelar erros no software.
6

PROJETOS DE CASOS TESTE


Qualquer produto trabalhado por engenharia pode ser
testado de duas maneiras:
1 - Conhecendo-se a funo especfica que um produto
projetado deve executar, testes podem ser realizados
para

demonstrar

que

cada

funo

operacional;
Abordagem: Teste de Caixa Preta

totalmente

PROJETOS DE CASOS TESTE

2 - Conhecendo-se o funcionamento interno de um


produto, testes podem ser realizados para garantir que
a operao interna do mesmo tenha desempenho de
acordo com as especificaes e que os componentes
internos foram postos prova.
Abordagem: Teste de Caixa Branca

TESTE CAIXA BRANCA


Teste de caixa branca uma abordagem de projeto de
casos de teste que usa a estrutura de controle do projeto
procedimental para derivar casos de teste.

Baseia-se

num

procedimentais.

minucioso

exame

dos

detalhes

TESTE CAIXA BRANCA


Os caminhos lgicos atravs do software so testados,
fornecendo-se casos de teste que pem prova conjuntos
especficos de condies e/ou laos.

O status do programa pode ser examinado em vrios


pontos para determinar se o esperado corresponde ao real.

10

TESTE CAIXA BRANCA


Com este mtodo ns podemos projetar casos de teste que:
Garantam que todos os caminhos independentes dentro de
um mdulo tenham sido exercitados pelo menos uma vez;
Exercitem todas as decises lgicas para valores falsos ou
verdadeiros;

Executem todos os laos em suas fronteiras e dentro de


seus limites operacionais;
Exercitem as estruturas de dados internas para garantir a
11

sua validade.

TESTE CAIXA BRANCA


Tipos de Teste Caixa Branca:
Teste de Caminho Bsico

Teste de Condio
Teste de Fluxo de Dados
Teste de Ciclo

12

TESTE DO CAMINHO BSICO


Tcnica de teste de caixa branca inicialmente
proposta por Tom McCabe.
Permite ao projetista do caso de teste derivar uma medida
da complexidade lgica de um projeto procedimental e usla para definir um conjunto bsico de caminhos de
execuo;

Complexidade

Ciclomtica

uma

mtrica

que

proporciona uma medida quantitativa da complexidade


lgica de um programa.
13

TESTE DO CAMINHO BSICO


Os casos de teste projetados para exercitarem este conjunto

bsico tm garantia de executar cada instruo do programa


pelo menos uma vez durante a atividade de teste.

Os seguintes passos devem ser aplicados:

14

TESTE DO CAMINHO BSICO


1. Usando o projeto ou o cdigo como base, desenhar o

grafo de fluxo correspondente;


2. Determinar a complexidade ciclomtica do diagrama de
fluxo resultante.
3. Determinar um conjunto base de caminhos linearmente
independentes.
4. Preparar casos de teste que vo forar a execuo de
cada caminho do conjunto base.
15

TESTE DO CAMINHO BSICO


Exemplo: Segmento de programa fonte e seu correspondente grafo de fluxo.
procedure:sort
1: do while records remain
read record;
2:
if record field1 = 0
1
3:
then process record;
store in buffer;
2
increment counter;
4
4:
else if record field2 = 0
5:
then reset counter;
6
5
6:
else process record;
store in file;
7
7:
endif
8
endif
8: enddo
9
9: end
16

TESTE DO CAMINHO BSICO

Caminho 1: 1-11
Caminho 2: 1-2-3-8-1 ...
Caminho 3: 1-2-4-5-7-8-1 ...
Caminho 4: 1-2-4-6-7-8-1 ...

1
2
4
6

R3 5

3
R2

7
8
9
17

R4

R1

TESTE DE CONDIO

Mtodo de Projeto de casos de teste que pe prova as


condies lgicas contidas em um mdulo de programa.
Condio Simples: varivel booleana ou expresso
relacional, precedida ou no por um operador NOT ()
Condio Composta: duas ou mais condies simples,
operadores booleanos e parnteses.
Tipos de Erros de uma Condio: erro de operador
booleano, erro de varivel booleana, erro de parnteses
booleano, erro de operador relacional, erro de expresso
aritmtica.
18

TESTE DE CONDIO
Teste de Ramos: Para uma condio C composta, os
ramos verdadeiro e falso de C e todas as condies simples
em C precisam ser executadas pelo menos uma vez.

Teste de Domnio: requer 3 ou 4 testes sejam derivados


para uma expresso relacional.

19

TESTE DE DOMNIO
Para uma expresso E1 <operador relacional> E2
3 testes so exigidos para tornar o valor de E1 >, = ou <
que o de E2.

Se <operador relacional> estiver incorreto e E1,E2 corretos,


esses 3 testes garantem a deteco de erro de operador
relacional.
Para detectar erros em E1 e E2, basta executar um teste
que faa o valor de E1 > ou < que o de E2, com uma

diferena menor possvel.


20

TESTE DE CICLO (LAOS)


Fundamental para a grande maioria de todos os
algoritmos implementados no software. Tcnica que
concentra na validade das construes de laos.
Laos Simples: deve ser aplicado o seguinte conjunto de
teste:

21

Pule o lao inteiramente;


Somente uma passagem atravs do lao;
Duas passagens atravs do lao;
m passagens atravs do lao, onde m < n;
n-1, n, n+1 passagens atravs do lao.

21

TESTE DE CICLO (LAOS)

Laos Aninhados:
1. Inicie pelo lao mais interno. Fixe os outros laos para
valores mnimos.
2. Realize testes de laos simples para o lao mais interno.
3. Trabalhe para fora, realizando testes para o lao seguinte,
mas mantendo todos os ciclos externos nos valores mnimos

4. Continue at que todos os laos tenham sido testados.


22

TESTE DE CICLO (LAOS)

Laos Concatenados:
1. Se laos independentes dos demais:
usar abordagem de laos simples.

2. Se contador de laos para o lao 1 for usado


como valor inicial para o lao 2:
usar abordagem de laos aninhados.

23

TESTE DE CICLO (LAOS)


Laos no estruturados:
Sempre que possvel, esta classe deve ser reprojetada para
refletir o uso das construes de programao estruturada.

24

TESTE CAIXA PRETA

Foco: requisitos funcionais do software


Possibilita a derivao de conjuntos de condies de
entrada que exercitem todos os requisitos funcionais para
um programa.

O Teste de Caixa Preta desconsidera a estrutura de


controle.

A ateno voltada ao domnio da informao.


25

TESTE CAIXA PRETA

O Teste de Caixa Preta no uma alternativa s tcnicas


Caixa Branca, mas ao contrrio, uma abordagem
complementar, que mais provavelmente descobrir uma
classe diferente de erros.

26

TESTE CAIXA PRETA


So realizados para responder as seguintes perguntas:
Como a validade funcional testada?
Como o comportamento e o desempenho testado?

Que classes de entrada faro bons casos de teste?


O sistema particularmente sensvel a certos valores?
Como as fronteiras de uma classe de dados isolada?
Que taxas e volumes de dados o sistema pode tolerar?
Que efeito combinaes especficas de dados tero sobre a

operao do sistema?
27

TESTE CAIXA PRETA


Desta forma o teste de caixa preta tenta encontrar erros
nas seguintes categorias:

Funes incorretas ou faltando;


Erros de interface;
Erros em estruturas de dados ou acesso a bases de dados
externas;
Erros de comportamento ou de desempenho;

Erros de inicializao e trmino.


28

TESTE CAIXA PRETA


Existem diferentes mtodos de testes de caixa preta que
podem ser subdivididos em:

Particionamento em Equivalncia
Anlise do Valor Limite
Teste de Matriz Ortogonal
Baseado em Grafo

29

TESTE CAIXA PRETA


Particionamento de Equivalncia

Mtodo de teste de caixa preta que divide o domnio


de entrada de um programa em classes de dados a

partir das quais os casos de testes podem ser


derivados.

Um caso de teste ideal descobre sozinho uma classe


de erros que, de outro modo, poderia exigir que
muitos casos fossem executados antes que o erro
geral fosse observado.

30

TESTE CAIXA PRETA


Particionamento de Equivalncia
As classes de equivalncia podem ser definidas,
conforme as seguintes diretrizes:

1. Se uma condio de entrada especificar um


intervalo, uma classe de equivalncia vlida e duas
classes de equivalncia invlidas so definidas.
2. Se uma condio de entrada exigir um valor
especfico, uma classe de equivalncia vlida e duas

invlidas so definidas.
31

TESTE CAIXA PRETA


Particionamento de Equivalncia
As classes de equivalncia podem ser definidas,
conforme as seguintes diretrizes:

3. Se uma condio de entrada especificar um


membro de um conjunto, uma classe de equivalncia
vlida e uma invlida so definidas.
4. Se uma condio de entrada for booleana, uma
classe de equivalncia vlida e uma invlida so

definidas.
32

TESTE CAIXA PRETA


Anlise do Valor Limite
Percebe-se que um nmero maior de erros tende a
ocorrer mais nas fronteiras do domnio de entrada do que
no centro. A anlise de valor de limite leva escolha de
casos de teste que pem prova os valores fronteirios.
uma tcnica que complementa o particionamento de
equivalncia: em vez de selecionar qualquer elemento de
uma classe de equivalncia, a BVA leva seleo de
casos de teste nas extremidadesda classe.
33

TESTE CAIXA PRETA


Anlise do Valor Limite

Qualquer nmero
(neste intervalo)

A anlise do valor limite leva a novos casos de teste


referentes a valores adjacentes aos limites. A seleo de
tais casos adicionais, aumentam a probabilidade de se
detectar uma falha.
34

TESTE CAIXA PRETA


Teste de matriz ortogonal

O teste de matriz ortogonal pode ser aplicado a problemas

nos quais o domnio de entrada relativamente pequeno,


mas muito grande para acomodar um teste exaustivo.

O objetivo do teste a construo de caso de teste com


uma visualizao geomtrica associada aos valores de
entrada de uma aplicao.

35

TESTE CAIXA PRETA


Para ilustrar, vamos considerar a funo envie para uma
aplicao de fax.

Neste exemplo, so passados quatro

parmetros: P1, P2, P3 e P4. Cada parmetro assume trs

valores discretos. P1 assume, por exemplo, os valores:


P1=1, enviar agora;

P1=2, enviar aps 1 hora;


P1=3, enviar depois da meia-noite;
P2, P3 e P4 tambm assumiriam valores, 1, 2 e 3,
significando outras funes de envio.
36

TESTE CAIXA PRETA


Matriz ortogonal para a funo envie da aplicao de fax:
Casos
de Teste
1
2
3
4
5
6
7
8
9
37

Parmetros de Teste
P1
P2
P3
P4
1
1
1
1
1
2
2
2
1
3
3
3
2
1
2
3
2
2
3
1
2
3
1
2
3
1
3
2
3
2
1
3
3
3
2
1

TESTE CAIXA PRETA


Baseado em grafo
O teste baseado em grafos leva em considerao os objetos
modelados no software e as relaes que os unem.

A ideia definir uma srie de testes que verificam se os


objetos tm a relao esperada uns com outros.
Um grafo uma coleo de ns que representam objetos,
ligaes que representam as relaes entre objetos, peso
de n que descreve as propriedades de um n e pesos de

ligao que descrevem uma caracterstica de uma ligao.


38

TESTE CAIXA PRETA


Baseado
em grafo

39

TESTES DE SOFTWARE AULA 4


Prof. Ulisses Sperle Graa
Rio de Janeiro, 27 de agosto de 2011

TESTE NO PROGRAMA
TESTE DE APLICAES DA WEB

OBJETIVOS DESTA AULA


1. Compreender tcnicas de teste de ambiente web;
2. Definir testes de software em ambiente web;

3. Implementar testes de software em ambiente web;


4. Avaliar testes de software em ambiente web.

INTRODUO
Com o crescimento da Internet e a evoluo das tecnologias
envolvidas, as aplicaes na WEB tambm evoluram. Hoje grande
parte dos negcios da organizaes tambm esto na WEB e
consequentemente ocorreu um aumento nos nmeros de

aplicaes desenvolvidas para este fim.

INTRODUO
O teste de uma aplicao WebApp (aplicaes para Web) um
conjunto de atividades relacionadas com um nico objetivo:

Descobrir erros

Mas como?

INTRODUO
Para atingir este objetivo deve ser utilizada uma estratgia
de teste que abrange as revises e o teste executvel.

O processo de teste comea focando os aspectos visveis


da Aplicao ao usurio e abrange os aspectos de
tecnologia e infraestrutura, neste caso em sete etapas de
teste:

INTRODUO
no contedo,
na funo,
na usabilidade,

na navegabilidade,
no desempenho,
na capacidade,
na segurana das aplicaes e etc.

INTRODUO
A qualidade, segundo Pressman (2011) incorporada a
uma aplicao

Web como consequncia de um bom

projeto.
No se pode testar a qualidade. Se ela no estiver l
antes de voc comear a testar, no estar l quando

voc tiver terminado de testar. (Pressman).


A qualidade incorporada ao software em todo o processo
de engenharia de software.
8

CONCEITO DE TESTE NA WEB


A aplicao adequada de mtodos e ferramentas, RTFs e
um gerenciamento e medio slidos, todos levam
qualidade que confirmada durante o teste.

A qualidade avaliada aplicando-se uma srie de revises


tcnicas e de um processo de teste com o objetivo de
examinar uma ou mais das seguintes dimenses de
qualidade:

DIMENSES DE QUALIDADE

Segurana

Interoperabilidade

Compatibilidade

Contedo

Funo

Estrutura

Qualidade

Desempenho

Usabilidade

Navegabi
-lidade

10

DIMENSES DE QUALIDADE
Contedo: avaliado no nvel semntico e sinttico. No
nvel sinttico examina-se a ortografia, pontuao e
gramtica. No nvel semntico so verificadas a exatido,

consistncia e ausncia de ambiguidade das informaes.

Funo: testada para descobrir erros que indicam falta de


conformidade com os requisitos do cliente.

11

DIMENSES DE QUALIDADE
Estrutura: avaliada para assegurar o fornecimento
apropriado do contedo e funo da aplicao. Que seja
extensvel e possa ser mantida medida que novo

contedo ou funcionalidade adicionado

Usabilidade: testada para garantir que cada categoria de


usurio seja suportada pela interface.

12

DIMENSES DE QUALIDADE
Navegabilidade: testada para assegurar que toda a
sintaxe e semntica de navegao sejam experimentadas
para descobrir quaisquer erros de navegao.

Desempenho: testado sob uma variedade de condies


de operao, configurao e carga para assegurar que o
sistema responda interao com o usurio e suporte
cargas extremas sem degradao inaceitvel de operao.

13

DIMENSES DE QUALIDADE
Compatibilidade: testada executando-se a aplicao em
uma variedade de diferentes configuraes hospedeiras
tanto no lado cliente quanto no lado servidor.

Interoperabilidade: testada para garantir que a aplicao


tenha uma interface adequada com outras aplicaes e/ou
bases de dados.

14

DIMENSES DE QUALIDADE
Segurana: testada para investigar vulnerabilidades
potenciais e tentar explorar cada uma delas. Qualquer
tentativa bem-sucedida de invaso considerada falha de

segurana.

15

O PROCESSO DE TESTE NA WEB


O processo de teste da aplicao Web comea com testes
que verificam o contedo e a funcionalidade da interface,
posteriormente so verificados aspectos da arquitetura do

projeto e da navegao da aplicao e finalizando com os


testes que examinam os recursos tecnolgicos.

Diversos deste testes no so aparentes para o usurio


final.

16

O PROCESSO DE TESTE NA WEB


Tarefas importantes:
1. Revise os requisitos dos interessados. Identifique metas
e objetivos-chave do usurio. Revise os casos de uso

para cada categoria de usurio.


2. Estabelea prioridades para garantir que cada meta e
objetivo do usurio seja testado.
3. Defina a estratgia de teste da aplicao descrevendo
os tipos de teste que sero conduzidos.

4. Desenvolva um plano de testes.


17

O PROCESSO DE TESTE NA WEB


Tarefas importantes (cont.):
5. Execute testes de unidade. Revise o contedo quanto
erros sintticos e semnticos.

6. Realize testes de integrao. Conduza testes de


navegao.
7. Realize testes de configurao. Avalie a configurao do
lado do cliente e do lado do servidor.
8. Conduza testes de desempenho.

9. Conduza testes de segurana.


18

O PROCESSO DE TESTE NA WEB


Podemos observar melhor o processo de teste na Web
atravs da figura adiante, representado atravs de uma
pirmide, os elementos que so visveis ao usurio, so

testados em primeiro lugar.


O fluxo do nosso processo de teste comea da esquerda

para direita e de cima para baixo, comeando pelo teste de


contedo, teste de interface, teste de navegao, de
componente e finalizando com os testes de configurao,

desempenho e segurana.
19

O PROCESSO DE TESTE NA WEB

20

O PROCESSO DE TESTE NA WEB


1. O modelo de contedo 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 aplicao revisto para


descobrir erros de navegao;
4. A interface com o usurio testada para descobrir erros
nos mecanismos de apresentao e/ou navegao;
5. Os componentes funcionais so submetidos a testes de

unidade;
21

O PROCESSO DE TESTE NA WEB


6. testada a navegao por toda a arquitetura;
7. A aplicao Web implementada em uma variedade de
configuraes ambientais diferentes e testada quanto

compatibilidade com cada configurao;


8. So executados testes de segurana na tentativa de
explorar vulnerabilidades na Aplicao ou em seu
ambiente;
9. So realizados testes de desempenho;

22

O PROCESSO DE TESTE NA WEB


10. A aplicao testada por uma populao de usurios
finais controlados e monitorados e os resultados de suas
interaes com o sistema so avaliados quanto a erros

de contedo e navegao, usabilidade, compatibilidade,


segurana, confiabilidade e desempenho.

23

TESTE DE CONTEDO
O teste de contedo tenta descobrir erros antes que sejam
encontrados pelos usurios. Ele combina tanto as revises,
j estudadas nas aulas anteriores, quanto gerao de

casos de tese executveis.


Os testes de contedo tm trs importantes objetivos:
1. Descobrir erros de sintaxe;
2. Descobrir erros de semntica
3. Encontrar erros na organizao ou estrutura do

contedo apresentado ao usurio final;


24

TESTE DE CONTEDO
O revisor dever responder as seguintes perguntas:
As informaes so precisas?
As informaes so concisas e direcionadas ao assunto?
fcil para o usurio entender o layout do contedo?
As informaes apresentadas so consistentes internamente

e consistentes com as apresentadas em outros objetos?


Foram fornecidas referncias apropriadas para todas as
informaes derivadas de outras fontes?
25

TESTE DE CONTEDO
O revisor dever responder as seguintes perguntas:
O contedo ofensivo, confuso ou d margem a litgio?
O contedo desrespeita os direitos autorais existentes ou de
marcas registradas?
O contedo contm links que complementam o contedo

existente? Os links esto corretos?


O estilo esttico do contedo est em conflito com o estilo
esttico da interface?
26

TESTE DE INTERFACE COM O USURIO


A verificao e validao de uma interface de usurio ocorre
em trs pontos distintos:
Durante a anlise garantir que esteja de acordo com os
requisitos do cliente;
Durante o projeto garantir que critrios genricos de
qualidade e que tpicos especficos foram tratados;

Durante o teste execuo de tpicos especficos


relativos interao como usurio e fornece uma
avaliao final da usabilidade.
27

TESTE DE INTERFACE COM O USURIO


Tem como objetivo descobrir erros relacionados com os
mecanismos especficos da interface e descobrir erros na
maneira como a interface implementa as semnticas de

navegao, as funcionalidades da aplicao ou ainda na


exibio do contedo.

Desta forma podemos distinguir basicamente quatro tipos de


testes:

28

TESTE DE INTERFACE COM O USURIO


Testes de mecanismos de interface: Avalia a interao de
cada mecanismos oferecido ao usurio atravs da interface:
link, formulrios, script executado pelo cliente, janelas pop up

e etc.

Teste de semntica da interface: Avalia como o projeto se


preocupa com os usurios.

29

TESTE DE INTERFACE COM O USURIO


Teste de usabilidade: determina o grau com o qual a
interface da aplicao facilita a vida do usurio.

Teste

de

compatibilidade:

Diferentes

computadores,

dispositivos de imagem, sistemas operacionais, navegadores


e velocidades de conexo de rede pode ter influncia
significativa na operao da aplicao Web.

30

TESTE DE COMPONENTE
O teste de componente, tambm conhecido como teste de
funo, tem como objetivo tentar descobrir erros nas funes
da aplicao Web.

Cada uma destas funes um componente de software que


pode ser implementados atravs de diferentes linguagens e
testados atravs de teste de caixa-preta ou ainda de caixabranca, ambos j estudados.

31

TESTE DE COMPONENTE
Cada caso de teste de componente especifica todos os
valores de entrada e sada esperada a ser fornecida pelo
componente.

Em muitas situaes, a execuo correta de uma funo da


aplicao est ligada ao interfaceamento correto com um
banco de dados que pode ser externo a aplicao, desta
forma, o teste de banco de dados torna-se parte importante

do teste de componente.
32

TESTE DE NAVEGAO
Um usurio navega por uma aplicao 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 decises a tomar.

33

TESTE DE NAVEGAO
Seu objetivo garantir que os mecanismos que permitem ao
usurios navegar atravs da aplicao Web estejam todos
em funcionamento e que cada unidade semntica de

navegao possa ser alcanada pela categoria apropriada de


usurio.

Desta forma este tipo de teste abrange:


Sintaxe

Semntica
34

TESTE DE NAVEGAO - SINTAXE


Segundo Pressman, neste tipo de teste os mecanismos de
navegao so verificados para garantir que cada um
execute sua funo planejada e garantir que os erros sejam

encontrados antes que a aplicao entre no ar:

Links de navegao: Cada link dever ser testado para


assegurar que o contedo ou funcionalidade apropriada
sejam alcanados quando o link escolhido.

35

TESTE DE NAVEGAO - SINTAXE


Redirecionamentos: Quando um usurio solicita uma URL
no existente ou seleciona um link cujo contedo foi
removido, exibida uma mensagem para o usurio e a

navegao redirecionada para outra pgina.

Marcadores de pginas (Booksmarks): Apesar de ser uma


funo do navegador, dever ser testado para assegurar que
possa ser extrado um ttulo de pgina com significado

quando o marcador for criado.


36

TESTE DE NAVEGAO - SINTAXE


Mapas do site: Como o mapa do site fornece uma tabela
completa de contedo para todas as pginas da web, cada
entrada dever ser testada.

Dispositivos de busca interna: Muitas aplicaes, devido a


quantidade

de

informaes

existentes,

implementam

mecanismos de busca. Dever ser testado o teste destes


mecanismos para validar a preciso e a totalidade da busca.

37

TESTE DE NAVEGAO - SINTAXE


Molduras e conjunto de molduras: Cada moldura tem o
contedo de uma pgina web especfica. Um conjunto de
moldura permite que vrias pginas sejam exibidas ao

mesmo tempo. O conjunto de molduras dever ser testado


quanto ao correto contedo, layout,

dimensionamento

apropriados e quanto a compatibilidade com o navegador.

38

TESTE DE NAVEGAO - SEMNTICA


A unidade semntica de navegao (NSU) pode ser
exemplificada por um conjunto de caminhos de navegao
que conectam ns de navegao (por exemplo, pginas

Web, objetos de contedo ou funcionalidade) que permite ao


usurio satisfazer requisitos especfico definidos por um ou
mais casos de uso para uma categoria de usurio.

Neste caso o teste semntico dever responder as seguintes

perguntas:
39

TESTE DE NAVEGAO - SEMNTICA


A NSU atendida sem erro?
Cada n de navegao acessvel no contexto dos
caminhos de navegao definidos para a NSU?
Todos os caminhos relevantes foram testados?
Se forem fornecidas instrues pela interface de usurio
para ajudar na navegao as instrues so corretas e
inteligveis medida que a navegao ocorre?

40

TESTE DE NAVEGAO - SEMNTICA


Existe algum mecanismo para voltar a um n de
navegao anterior e ao incio do caminho de navegao?
Se uma funo executada em um n e ocorre um erro
no processamento da funo, a NSU pode ser completada?
Todos os ns podem ser acessados do mapa do site? Os

nomes dos ns tm significado para os usurios finais?

41

TESTE DE NAVEGAO - SEMNTICA


O teste de navegao, bem com o teste de interface e de
usabilidade, devem ser feitos alm dos testadores,
tambm por diferentes clientes, sempre que possvel!

42

TESTE DE CONFIGURAO
O objetivo do teste de configurao (Pressman, 2011)

testar um conjunto de provveis configuraes do cliente e


do servidor para assegurar que a experincia do usurio

ser a mesma em todos os casos e isolar erros que podem


ser especfico a uma determinada configurao.

43

TESTE DE CONFIGURAO
Lado Servidor os casos de teste so projetados para
verificar se a configurao do servidor pode suportar a
aplicao sem erro. Perguntas a serem respondidas:
A aplicao totalmente compatvel com o sistema
operacional do servidor?

Os arquivos de sistema, diretrios e dados de sistema


relacionados so criados corretamente quando a aplicao
est operacional?
44

TESTE DE CONFIGURAO
As medidas de segurana permitem que a aplicao
seja executada sem a interferncia ou degradao do
desempenho?
A aplicao est adequadamente integrada com o
software de banco de dados?

Os

scripts

utilizados

pela

aplicao

corretamente?

45

executam

TESTE DE CONFIGURAO
Lado Cliente foca a compatibilidade da aplicao com
configuraes dos seguintes componentes:
Hardware:

CPU,

memria,

armazenamento

dispositivo de impresso;
Sistemas

operacionais:

Linux,

Macintosh

OS,

Microsoft, S.O. Mvel.


Software Navegador: Firefox, Safari, Internet Explorer,
Opera, Chrome e outros.
46

TESTE DE CONFIGURAO
Componentes de interface de usurio: Active X, java
Applets e outros.
Plug-ins: QuickTime, RealPlayer e outros.
Conectividade: Cabo, DSL, modem , WIFI.
Estes testes devem ser projetados onde cada categoria

de usurio seja avaliada para determinar as provveis


configuraes que sero encontradas, reduzindo assim o
nmero de variveis de configurao para um nmero
gerencivel.
47

TESTE DE SEGURANA
As aplicaes Web e os ambientes cliente e servidor nos
quais as aplicaes esto alojadas representam um alvo para
invasores externos, funcionrios insatisfeitos, concorrentes

desonestos e qualquer outro que queira roubar informaes


sigilosas, modificar contedo maliciosamente, degradar o
desempenho ou desabilitar funcionalidades.

Estes testes so projetados para investigar vulnerabilidades:

48

TESTE DE SEGURANA
Vulnerabilidades:
no ambiente do lado do cliente,

Na comunicao de rede que ocorrem quando os dados


so passados do cliente para o servidor
Na comunicao de rede que ocorrem quando os dados
so passados do servidor para o cliente
no ambiente do lado servidor.

49

TESTE DE DESEMPENHO
A medida que em que aumenta o nmero de usurios nas
aplicaes web, consequentemente ocorre um aumento do
nmero de transaes online ou na quantidade de dados

atravs das operaes de download ou upload.

muito frustrante para um usurio quando uma aplicao


leva muitos minutos para carregar o contedo ou quando ao
recebe do servidor uma mensagem do tipo servidor

ocupado.
50

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 inteno entender como os sistemas respondem quando


a carga aumenta e ainda reunir mtricas que conduziro a
modificaes de projeto para melhorar o desempenho.

51

TESTE DE DESEMPENHO
Este tipo de teste ajudar a responder as seguintes questes:
O tempo de resposta do servidor degrada de forma a tornarse inaceitvel?
Em que ponto, sob o ponto de vista dos usurios, transaes
ou cargas de dados, o desempenho se torna inaceitvel?

Quais componentes do sistema so responsveis pela


degradao do desempenho?
Qual o tempo mdio de resposta para usurios sob diferentes
condies de carga?
52

TESTE DE DESEMPENHO
Para obter respostas a essas perguntas so feios dois testes
diferentes de desempenho:
Teste de carga

Teste de esforo (stress)

53

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 vrias condies de carga. So

utilizadas como condies de teste as seguintes variveis:


Nmero de usurios concorrentes (N)
Nmero de transaes on-line por usurios por unidade
de tempo (T)
Carga

de

dados

processados

pelo servidor

transao (D)
54

por

TESTE DE DESEMPENHO
medida que o teste feito, so realizadas permutaes nas
variveis de acordo com os limites de operao normal do
sistema e coletas uma ou mais das seguintes medidas:
Resposta mdia do usurio;
Tempo mdio para o download de uma unidade

padronizada de dados;
Tempo mdio para processar uma transao;

55

TESTE DE DESEMPENHO
Teste de Esforo (stress) uma continuao do teste de
carga, e desta forma utilizam as mesmas variveis: T, N, D,
porm com seus limites operacionais excedidos.
A finalidade deste teste responder as seguintes questes:
O sistema degrada ou o servidor desliga quando excedida

a capacidade normal de operao?

56

TESTE DE DESEMPENHO
O

software

servidor

gera

servidor

mensagens

no

disponvel? De uma maneira geral os usurios ficam cientes


de que no podem acessar o servidor?
O servidor coloca

as requisies por recursos em fila e

esvazia a fila quando a demanda de capacidade diminui?

So perdidas transaes quando a capacidade excedida?


A integridade dos dados afetada quando a capacidade
excedida?
57

TESTE DE DESEMPENHO
Quais valores de N, T e D foram o ambiente servidor a
falhar? Como a falha se manifesta? So mandadas
notificaes automticas para o pessoal de suporte tcnico

no local do servidor?
Se o sistema falha, quanto tempo demora at que volte a

ficar on-line?

58