Teste de WS - Compressed

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.
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
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

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

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
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
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
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

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,

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

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

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

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

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

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

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
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
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
Fora bruta
Mtodo mais comum e menos eficiente;
Usado quando os outros mtodos falham;

Faz-se
imensa
planejamento.
28
quantidade
de
teste,
mas
sem
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
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
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
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
TESTE NO PROGRAMA
TESTE CAIXA BRANCA E
TESTE CAIXA PRETA

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

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

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

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
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
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
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

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

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

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

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

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

Prof. Ulisses Sperle Graa
TESTE NO PROGRAMA
TESTE DE APLICAES DA WEB

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
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
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
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
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
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

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

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

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
20

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

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

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

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

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 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

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

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

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

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

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

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

Teste de WS - Compressed

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Teste de WS - Compressed

Diunggah oleh

Hak Cipta:

Format Tersedia

1 - Defina testes de software?

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

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

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

6 - Explique para que serve teste de integrao.

7 - Qual o objetivo do teste de sistema?

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

8 - Explique o modelo de hipoteses validao utilizado na depurao

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

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

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

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

13 - Explique o que deve ser verificado em relao dimenso

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

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

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

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

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

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

TESTES DE SOFTWARE AULA 1

Rio de Janeiro, 20 de agosto de 2011

Unidade 2 - Teste no projeto de sistema

Teste de caixa preta

Ferramentas de teste para sistemas em produo

O desenvolvimento de sistemas envolve uma srie de

logo no incio do processo, onde os objetivos podem estar

Por causa da inabilidade humana de realizar e de se

acompanhado de garantia de qualidade.

reviso de especificao, projeto e codificao.

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

passos de engenharia de software combinados.

DEFININDO O TESTE DE SOFTWARE

Qualquer atividade que, a partir da avaliao de um

desejados. (Bill Hetzel 1988).

DEFININDO O TESTE DE SOFTWARE

Uma estratgia de teste de software deve acomodar testes

DEFININDO O TESTE DE SOFTWARE

Testes podem ser usados para descobrir a presena de

Testes de software o processo de executar o software de

Para executar um teste eficaz, proceder a revises

tcnicas eficazes. Fazendo isso, muitos erros sero

Diferentes tcnicas de teste so apropriadas para

diferentes abordagens de engenharia de software e em

O teste e a depurao so atividades diferentes, mas

a depurao ocorre em consequncia de um teste.

Um bom caso de teste aquele que possui uma elevada

Um teste bem-sucedido aquele que revela um erro ainda

DIRETRIZES PARA O TESTE

Preparao: Preparao do ambiente de teste, incluindo

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.

da documentao do sistema (testes estticos).

INTERAO ENTRE OS CICLOS DE VIDA

programa, passando para os testes destinados a facilitar a

especificaes, em termos de garantia e de funcionalidade.

Normalmente feito pelos desenvolvedores.

combinao de componentes para verificar se ele funcionam

Componentes podem ser pedaos de cdigo, mdulos,