Qualidade de Software e Testes PDF

Fernando Pedrosa fpedrosa@gmail.
com
Sommerville, Ian. Software
Engineering. Editora: Addison Wesley.
Pressman, Roger S. Software
Engineering: A Practiotioners
Approach. Editora: McGraw-Hill.
RUP - www.wthreex.com/rup
IEEE TC FTD/IFIP WG 10.4
Fernando Pedrosa Lopes 2

Uma vez que o cdigo fonte tenha
sido gerado necessrio testar para
descobrir erros antes de entregar o
software para o cliente
O objetivo projetar uma srie de
testes com mxima probabilidade de
encontrar erros
So utilizadas tcnicas para:
Testar a lgica interna dos componentes
Testar as entradas e sadas das funes

Durante os estgios iniciais do
desenvolvimento, um Engenheiro de
Software executa todos os testes
Entretanto, medida que o processo
evolui, especialistas em testes podem
ser envolvidos

Corretiva
Correo de erros encontrados na
verificao ou na validao
Adaptativa
Adaptao a mudanas externas
Melhoria (perfectiva)
Melhorias requeridas pelos usurios
Preventiva ou de reengenharia
Abordagem pr-ativa com foco na
melhoria da manutibilidade

Falta (Fault)
Causa de uma falha (aspecto fsico)
Exemplo: cdigo incorreto ou faltando, defeito de hardware
Erro (Error)
Estado intermedirio, de instabilidade (aspecto de
informao)
Pode resultar em falha, se propagado at a sada
Falha (Failure)
Incapacidade do software de realizar a funo requisitada
(aspecto externo). Manifestao observvel.
Exemplo: terminao anormal, restrio temporal violada
Falta Erro Falha

Universo Interno
(Hardware ou
Software) Pode ou no ocorrer
Estado de Instabilidade

Como tornar os sistemas mais confiveis?
Preveno de faltas
Especificao rigorosa
Proteo de Hardware
Ambientes e linguagens apropriados
Tolerncia a falhas
Replicao/Redundncia
Isolamento do componente faltoso
Hot swapping

(Min. Comunicaes - CESPE 2008)
[109] Ao longo do desenvolvimento, artefatos produzidos podem ser
revisados, objetivando garantir que os mesmos apresentem, pelo
menos, a qualidade mnima especificada. No apenas o cdigo, mas
tambm outros artefatos podem ser revisados. Os defeitos encontrados
pelas revises referem-se faltas (fault), enquanto os defeitos
encontrados por testes so falhas do software, pois testes avaliam a
qualidade comparando o comportamento esperado com o observado.

(TRE/BA CESPE 2010)
[61] Segundo o IEEE, defeito um ato inconsistente cometido por um
indivduo ao tentar entender determinada informao, resolver um
problema ou utilizar um mtodo ou uma ferramenta; erro o
comportamento operacional do software diferente do esperado pelo
usurio, e que pode ter sido causado por diversas falhas; e falha uma
manifestao concreta de um defeito em um artefato de software, ou
seja, qualquer estado intermedirio incorreto ou resultado inesperado
na execuo de um programa.

todo um processo de ciclo de vida
que deve ser aplicado em cada estgio
do desenvolvimento do software
Tem dois objetivos principais:
O descobrimento de defeitos no sistema
A avaliao sobre se o sistema til e
adequado em uma situao operacional
V&V no garante que o software est
livre de defeitos, mas apenas garante
um certo nvel de confiabilidade

Refere-se ao conjunto de atividades
que garantem que o software
implementa corretamente as funes
especificadas
Estamos construindo o produto de forma correta?
Are we building the Product Right?
Principais atividades
Inspees (verificao esttica)
Testes (verificao dinmica)

Refere-se ao conjunto de atividades
que garantem que o software
construdo implementa o que o cliente
realmente desejava
Estamos construindo o produto certo?
Are we building the Right Product?
Principais atividades
Homologao, Testes de Aceitao (beta)
Revises, etc.

(MPOG ESAF 2008)
[13-B] Demonstrar ao desenvolvedor e ao cliente que o software
atende aos requisitos uma meta de validao do software.
(IPEA - CESPE 2008)
[85] A verificao assegura que o produto, como fornecido, ir atender o seu
uso pretendido, ou seja, que se est construindo o produto certo. E a validao
confirma que os produtos de trabalho refletem de forma apropriada os
requisitos que foram especificados, ou seja, que se est construindo o produto
corretamente.
(TRT5 - CESPE 2009)
[75] A diferena entre verificao e validao reside no fato de que a primeira
se refere ao conjunto de atividades que garante que o software realiza
corretamente uma funo especfica, enquanto a segunda refere-se a um
conjunto diferente de atividades que garante que o software que foi construdo
rastrevel s exigncias do cliente.

(MPU - FCC 2007)
[56] Considere as informaes abaixo em relao ao desenvolvimento
de sistemas:
I. executar um software com o objetivo de revelar falhas, mas que no
prova a exatido do software.
II. correta construo do produto.
III. construo do produto certo.
Correspondem corretamente a I, II e III, respectivamente,
a) validao, verificao e teste.

b) verificao, teste e validao.
c) teste, verificao e validao.
d) validao, teste e verificao.
e) teste, validao e verificao

Garantia da Qualidade Controle da Qualidade
Focada no processo Focada no produto
Orientada a preveno Orientada a deteco
Exemplos: metodologias Exemplos: checagem de
e padres de requisitos, testes de
desenvolvimento software, etc.
Garante que os
Garante que voc est
resultados do seu
fazendo as coisas da
trabalho esto de acordo
maneira correta
com o esperado

Alguns autores no diferenciam estas
atividades
Para Sommerville inclui Validao e
Verificao de Produtos, alm dos
Processos adequados
Para Pressman inclui um espectro
amplo de atividades, tais como
padronizao, revises, testes, etc.

(SERPRO - CESPE 2010)
[98] A garantia de qualidade tem como objetivo testar os produtos de
software de modo a identificar, relatar e remover os defeitos encontrados,
enquanto o controle da qualidade prov a gerncia snior da organizao
com a visibilidade apropriada sobre o processo de desenvolvimento.
(STJ CESPE 2008)
[97] Um processo de gerenciamento da qualidade do projeto tipicamente
visa garantir e controlar a qualidade. No controle da qualidade, so
executadas atividades planejadas e sistemticas visando garantir que o
projeto empregar os processos necessrios para atender aos requisitos. Por
sua vez, a garantia da qualidade, diferentemente do controle de qualidade,
monitora resultados do projeto a fim de determinar se eles esto de acordo
com os padres relevantes de qualidade e procura identificar meios para
eliminar as causas de resultados que sejam insatisfatrios.

Se preocupa com a anlise esttica
dos artefatos do sistema
Envolve pessoas examinando os
produtos de trabalho com o objetivo
de encontrar anomalias e defeitos
Pode ser suplementada por
ferramentas CASE de anlise esttica

Inspees e Testes so tcnicas
complementares e no opostas
Muitos defeitos podem ser encontrados
durante uma inspeo - testes podem
mascarar erros e necessitar de vrias
execues
Inspees no podem checar requisitos no
funcionais (desempenho, usabilidade, etc.)
Inspees checam a conformidade com a
especificao e no com as reais
necessidades do cliente

Inspees no necessitam da
execuo do sistema, portanto podem
ser aplicadas antes da implementao
Podem ser aplicadas a qualquer
representao do sistema
Requisitos
Projeto,
Cdigo, etc.
Tm se mostrado uma tcnica efetiva
para se descobrir erros no programa

Inspees aumentam o custo do
processo de desenvolvimento, no
incio
As equipes devem ser bem informadas
e ter acesso a especificaes precisas
Padres organizacionais devem ser
bem definidos
A gerncia pode utilizar os achados de
inspeo para avaliar (culpar)
indivduos
So abordagens formais para
documentar as revises do cdigo
A inteno de deteco de defeitos,
apenas (e no correo)
Defeitos podem ser
Lgicos (caminhos incorretos, clculos
errados, etc.)
Anomalias no cdigo (variveis no
inicializadas, laos incompletos, etc.)
No conformidade com padres

Procedimento:
Um resumo do sistema apresentado
equipe de inspeo
Cdigo e documentos associados so
distribudos equipe com antecedncia
A inspeo acontece e os erros
descobertos so anotados, de acordo
com um checklist
Uma nova inspeo pode ser necessria

Inspees de cdigo automatizadas
utilizam Analisadores Estticos
So ferramentas CASE que analisam o
cdigo fonte do sistema
Buscam e relatam erros em potencial
So bastante efetivos como um auxlio s
inspees, mas no a substituem
Tm um melhor custo-benefcio para
linguagens fracamente tipadas, onde o
compilador detecta poucos erros

Exemplos de possveis anlises:
Anlise de controle de fluxo
Checa a codificao de loops, cdigo
inalcanvel, etc.
Anlise de dados
Detecta variveis no inicializadas, variveis
que nunca so utilizadas, etc.
Anlise de interfaces
Checa a consistncia de declaraes de
rotinas e procedimentos e como so
utilizados

(STJ - CESPE 2008)
[73] Inspees e walkthroughs podem fazer parte de um processo de
verificao e validao, sendo realizadas por equipes cujos membros tm
papis definidos. Quando da inspeo de um cdigo, uma lista de
verificao de erros (checklist) usada. O contedo da lista tipicamente
independe da linguagem de programao usada.
(TSE - CESPE 2006)

[63-A] Inspees e walkthroughs podem ser usadas para revisar artefatos.
Uma walkthrough requer mais tempo de preparao dos revisores do que
uma inspeo, tambm exige que seja feito o acompanhamento das
solues dos problemas identificados e a coleta de mtricas associadas
reviso.

(TSE - CESPE 2006)
[63-B] Em uma inspeo, os participantes tm papis definidos. O
moderador conduz reunies e os inspetores devem, durante as reunies,
descrever os problemas identificados e solues para os mesmos.
(DETRAN - CESPE 2009)

[97] O processo de validao tem por objetivo estabelecer com os clientes
confiana quanto ao funcionamento adequado de um software. Enquanto
inspees de software ou revises por pares so consideradas validao
esttica, o teste consiste em uma tcnica dinmica de validao de
software. Os termos esttico ou dinmico so relativos necessidade ou
no do software ser executado.

Processo de executar um programa
com o objetivo de encontrar erros.
Um bom caso de teste aquele que
tem alta probabilidade de achar um
erro ainda no descoberto.
Um teste de sucesso aquele que
descobre um erro ainda no
descoberto.

O processo de testes no pode
garantir que o software est livre de
erros, ele pode apenas mostrar que
erros e defeitos de software esto
presentes.

Testes devem ser rastreveis aos
requisitos do cliente
Testes devem ser planejados muito
antes de serem executados
O princpio de Pareto se aplica a Testes
80% dos erros vo acontecer em 20% dos
componentes
Testes devem comear pequenos e
progredir para pedaos maiores

Testes exaustivos no so possveis
impossvel executar todos os caminhos
existentes em um programa
Para terem o mximo de efetividade,
testes devem ser, preferencialmente,
conduzidos por terceiros

Um bom teste deve ter alta
probabilidade de encontrar erros
Um bom teste no deve ser redundante
Todo teste deve ter um propsito diferente
Um bom teste deve ser representativo
na sua classe
Um bom teste no deve ser nem muito
simples nem muito complexo [Pressman]

Abordagem Funcional (caixa preta)
Focada nas entradas e sadas especificadas
nos requisitos funcionais
Abordagem Estrutural (caixa branca)
Focada nas estruturas internas dos
procedimentos do sistema
Abordagem Mista (caixa cinza)
um meio termo entre caixa preta e branca
Algum conhecimento sobre as estruturas
internas utilizado para executar testes
mais bem informados
Baseada em prs e ps condies
Geralmente utilizada nas etapas posteriores
da disciplina de testes
Busca erros nas seguintes categorias (dentre
outras):
Funes incorretas ou inexistentes
Erros de comportamento ou desempenho
Erros de inicializao e trmino, erros de interface
Principais tcnicas: testes baseados em
grafos, matriz ortogonal, anlise de valores
limtrofes, particionamento de equivalncias

Graph-based testing methods
Toda aplicao construda por
objetos
A tcnica identifica todos estes objetos
e gera grficos para represent-los
Os objetos e relacionamentos so
testados para descobrir erros e
comportamentos inesperados

Menu de
seleo A seleo do menu gera Janela do
de Novo Documento
(tempo de gerao < 1.0 seg)
Arquivo
Atributos:
Dimenso: config default
Contm
ou preferncia
Texto do Fundo: branco
Documento Cor do texto: cor default
ou preferncia

Tcnica baseada em dividir o domnio
de entradas de um programa em
classes de dados
Cada classe de dados chamada de
partio de equivalncia
Casos de Teste so gerados
considerando cada partio de
equivalncia

Como guia, deve-se considerar
entradas do tipo:
Faixa de Valores
1 partio vlida, 2 invlidas
Valor especfico
1 partio vlida, 2 invlidas
Conjunto especfico de valores
1 partio vlida, 1 invlida
Entrada booleana
1 partio vlida, 1 invlida

Exemplos (faixas de valores)

sabido que a maioria dos erros
acontece nos limites do domnio de
entrada, e no no centro
Os testes devem ser gerados
considerando esses valores limtrofes
Nmeros mximos e mnimos
Um a mais do que o mximo
Um a menos do que o mnimo
utilizada em conjunto com a tcnica de
Particionamento de Equivalncia

(TRE/BA - CESPE 2010)
[79] Teste funcional uma tcnica para se projetar casos de teste na qual
o programa ou sistema considerado uma caixa-preta e, para test-lo,
so fornecidas entradas e avaliadas as sadas geradas.
(CEF - CESPE 2010)

[57-C] Relativamente ao modelo de caixa-cinza, o teste de software caixa-
preta apresenta maior dependncia no trabalho entre implementador e
testador.
(CEF - CESPE 2010)

[57-D] O teste de software caixa-preta, relativamente ao modelo de caixa-
cinza, apresenta maior dependncia de conhecimento a respeito dos
programas-fontes a serem testados.

(TRT5 - CESPE 2008)
[74] Entre os tipos de testes de caixa preta, encontram-se o teste baseado
em grafos; o particionamento de equivalncia; a anlise de valor-limite; e
o teste de matriz ortogonal.
(MPOG - ESAF 2008)

[13-C] o particionamento de equivalncia uma maneira estratgica de
aplicar testes de software.

Os testes so gerados a partir de uma
anlise dos caminhos lgicos
possveis de serem executados
necessrio conhecimento do
funcionamento interno dos
componentes do software
Objetivos
Garantir que todos os caminhos
independentes de um mdulo sejam
executados pelo menos uma vez

Objetivos (continuao)
Realizar todas as decises lgicas para
valores falsos e verdadeiros
Executar laos dentro dos valores limites
Avaliar as estruturas de dados internas
Principais tcnicas
Testes de caminhos
Testes de estruturas de controle (laos,
estruturas condicionais, etc.)
Complexidade ciclomtica (mtrica)

Mtrica que fornece uma medida
quantitativa da complexidade lgica de um
programa
Quando usada no contexto de testes caixa
branca, denota o nmero de caminhos
possveis dentro de um mdulo
Nos d uma idia do limite superior necessrio!

(SERPRO CESPE 2010)
[85] Com relao ao emprego de tcnicas para a realizao de testes
de software, correto afirmar que haver maior diminuio da
dependncia de acesso s especificaes arquiteturais de um
sistema se o testador empregar a tcnica de caixa-branca (white-
box), em vez das tcnicas de caixa-cinza (gray-box) e de caixa-
preta (black-box).
(CEF - CESPE 2010)

[57-B] O aumento na medida de complexidade ciclomtica de um
programa introduz mudanas significativas no refinamento de uma
abordagem do tipo caixa-preta.

(CEF CESPE 2010)
[57-E] medida que avana o nvel de integrao dos mdulos de um
software, mais vivel se torna a adoo do mtodo de caixa-branca
para desenho do teste de software.
(CEF CESPE 2010)

[57-A] Para aderncia abordagem de software caixa-branca, podem
ser empregados testes de fluxo de controle e de dados, que no so
apoiadores diretos em testes de caixa-preta.
(MPOG - ESAF 2008)

[13-D] O teste estrutural uma estratgia que se baseia na anlise da
especificao de um programa para ajudar na seleo de casos de
teste.

Os testes geralmente so agrupados
de acordo com o momento no qual
eles so executados ou pelo nvel de
especificidade do teste

Primeiro nvel de testes, onde
componentes individuais so testados
para assegurar que os mesmos
operam de forma correta
Componentes podem ser:
Mtodos individuais dentro de um objeto
Classes com vrios atributos e mtodos
Componentes que tenham sua estrutura
interna bem conhecida
Ferramenta mais utilizada (Java): JUnit

Framework de cdigo aberto, que
prov o ambiente necessrio para
testar cdigos em Java
A maioria das IDEs (Eclipse, Netbeans,
JDeveloper, etc.) incorpora-o dentro
do seu ambiente, tornando o uso mais
fcil

Classe a ser testada
Calculadora.java
Classe contendo os casos de teste
quem realmente executa os testes na
classe a ser testada
CalculadoraTest.java
Chamador (driver) dos testes
Chama as classes contendo os testes
Normalmente utilizado automaticamente
atravs das IDEs

Classe a ser testada
Classe contendo os
casos de teste
Assertiva

(PETROBRAS - CESGRANRIO 2010)
[13-A] A utilizao de testes unitrios faz com que seja desnecessria
a fase de testes de aceitao, pois garantido que o software passou
por todos os testes de funcionamento necessrios.
(PETROBRAS - CESGRANRIO 2010)

[13-B] A utilizao de testes unitrios ajuda a verificar se alteraes
introduzidas por um dos membros de uma equipe de tamanho mdio
ou grande no causaram efeitos colaterais em mdulos de outros
membros da equipe.

(SERPRO - CESPE 2010)
[83] A atividade de teste unitrio de software , conforme os modelos de
ciclo de vida de software vigentes, realizada de forma mais eficaz no
escopo de implementao e da construo de software - nas quais a
codificao de uma unidade executvel de software feita -, quando
comparada situao em que o teste unitrio realizado
simultaneamente ao teste de integrao.
(TRE/MT - CESPE 2010)

[40-A] JUnit um framework open-source (arcabouo livre) para escrever
e executar testes automaticamente, sem necessidade de escrever cdigo
adicional.
[40-C] A classe AssertEquals(a,b) compara dois valores. O teste

executado com sucesso se a.equals(b).

Integra e testa os componentes de um
sistema com o objetivo de encontrar
problemas durante suas interaes
Integrao Top-Down
Desenvolve o esqueleto do sistema e o preenche
com os componentes do sistema
Integrao Bottom-Up
Integra os componentes de infraestrutura e depois
adiciona componentes funcionais
Para facilitar a localizao de erros, sistemas
devem ser integrados gradualmente

Teste
Componente

(IPEA - CESPE 2008)
[58] Os testes de integrao verificam se os componentes do sistema
funcionam em conjunto, se os componentes so chamados
corretamente e se os componentes transferem dados corretos via suas
interfaces. Nesses testes, os componentes so testados interligados;
podem ser necessrios drivers e stubs para simular componentes
ainda no implementados; e, em sistemas de software orientados a
objeto, os stubs podem ser classes.
(TRE/PR - CESPE 2009)

[83] Nos testes de integrao, realizados antes dos testes unitrios, os
componentes so construdos e testados separadamente.

Ao final dos testes de integrao, o
software est consolidado e iniciam-se
os testes de aceitao
A finalidade demonstrar a
conformidade com os requisitos de
software
O ambiente utilizado deve ser o mais
prximo possvel do ambiente real
Os mais comuns so Testes Alfa ou
Beta
virtualmente impossvel para o
desenvolvedor prever como o software
ser utilizado pelo usurio
So necessrios testes conduzidos pelo
cliente nas instalaes do
desenvolvedor
O desenvolvedor anota os erros e
problemas que possam ocorrer
Acontece em ambiente controlado

conduzido em um ou mais locais do
cliente, pelo usurio final do produto
O desenvolvedor geralmente no est
presente
O usurio anota todos os problemas
que possa encontrar e os envia para o
desenvolvedor frequentemente
Acontece em ambiente real

Software apenas um elemento de
todo um sistema computacional maior
necessrio test-lo no ambiente
operacional, onde so considerados
Hardware e Pessoas
Processos e informaes
Outros sistemas, etc.
So conduzidos em um ambiente
completo e integrado, por vrias
pessoas (no s os desenvolvedores)

[39-D] O teste alfa conduzido pelo cliente em seu ambiente de uso final.
(TSE - CESPE 2006)

[55-C] Os testes so realizados em vrias fases de um desenvolvimento.
Testes de unidade so de baixo nvel, testes de sistema so executados
aps os de integrao, testes beta empregam apenas desenvolvedores.
(EPE CESGRANRIO 2010)

[43] Um novo sistema de informao interno de uma empresa
est sendo testado por um grupo restrito de usurios, fora
do ambiente dos desenvolvedores. Isso caracteriza o teste
(A) de unidade. (B) de usabilidade.
(C) alfa. (D) beta.
(E) de stress.

Cada vez que um mdulo adicionado
ao sistema, o software muda
Novas entradas e sadas surgem
Podem ser executados novos caminhos
A lgica de controle muda
Teste de regresso visa a executar um
subconjunto de testes que j foram
executados com o intuito de garantir
que as mudanas no propagaram
efeitos indesejados

O termo usado em vrias reas e
refere-se ao primeiro teste realizado
depois de integrar os componentes
Em Software, aplicado aps cada
montagem (build) do produto para
verificar sua funcionalidade bsica
O intuito deve ser o de encontrar erros
que tm a maior probabilidade de
atrasar o projeto (show stopper errors)

Muitos sistemas devem se recuperar
de falhas e voltar ao processamento
dentro de um tempo pr-estabelecido
Teste de recuperao fora o software
a falhar de vrias formas e verifica que
a recuperao foi feita de forma
adequada
A recuperao pode ser automtica ou
manual

Tem o objetivo de verificar que
mecanismos de proteo
implementados no sistema iro, de
fato, proteg-lo de ataques
O testador tenta penetrar no sistema
Dado tempo suficiente, um teste de
segurana ir penetrar o sistema
papel do desenvolvedor do sistema
assegurar que isto custe mais caro que os
ganhos obtidos

Inicialmente, testes caixa branca e caixa
preta tem o intuito de testar o sistema sob
condies normais
Testes de carga visam a confrontar
programas com situaes anormais
Tm carter destrutivo
At onde ele aguenta?
Podem ser estressados
Memria (vrios objetos criados)
I/O (muitas interrupes por segundo)
Disco (busca por dados), etc.

Pode ocorrer durante todos os
estgios de testes
Visa a garantir que o sistema atende
aos nveis de desempenho e tempo de
resposta acordados com o usurio e
definidos nos requisitos

Avalia o sistema do ponto de vista do
usurio final
Enfatiza o seguinte:
Fatores humanos
Esttica
Consistncia na interface do usurio
Ajuda online e contextual
Assistentes e agentes (wizards)
Documentao do usurio
Material de treinamento

(PRODEST - CESPE 2006)
[101] O XP um processo que visa a um desenvolvimento gil e
portanto no recomenda os testes de unidade, pois eles consomem
muitos recursos. Durante o desenvolvimento, o primeiro teste
recomendado o smoke test que foca os detalhes de funcionamento.
O smoke test realizado aps as unidades serem integradas. Aps o
smoke test, realizado o teste de sistema.
(TRT16 - FCC 2009)

[48] H um tipo de teste que vislumbra a destruio do programa por
meio de sua submisso a quantidades, frequncias ou volumes
anormais que o teste
(A) de recuperao. (B) de configurao. (C) beta. (D) de desempenho.

(E) de estresse.

o processo que resulta na remoo
de um erro encontrado
Ocorre como uma consequncia de
um teste de sucesso (um teste que
encontrou erros)
Envolve formular uma hiptese sobre
o comportamento do sistema e testar
essa hiptese para achar os erros

2
1
3
Casos de
Teste Execuo dos
casos
Testes
adicionais Causas
suspeitas Resultados
Testes de regresso
Correes 4
Causas
identificadas

Fora Bruta
Popula-se o sistema com escritas ao console para
tentar encontrar algum trao de erro durante a
execuo
o mtodo menos eficiente de todos
Backtracking
Comeando a partir de onde o erro ocorreu,
deve-se rastrear o cdigo manualmente at a
fonte do erro
Eliminao de causa
Uma hiptese de causa elaborada e os dados
relacionados ao erro so utilizados para prov-la

[43] Existem vrias maneiras de se depurar (debug) programas.
Algumas delas envolvem conhecimento, prtica e bom senso do
programador. Acerca de pontos que so importantes para depurar
programas, julgue os itens a seguir.
I possvel encontrar falhas nos programas por meio da reproduo do

erro em testes.
II Quanto maior a entrada de dados nos testes, mais simples encontrar
o problema e mais fcil encontrar a soluo da falha.
III Em um programa modular, o processo de encontrar falhas requer
uma menor variao de informaes de entrada, de modo que o
programador possa encontrar o mdulo com erros.
IV A passagem de parmetros para variveis auxiliares evita o uso de
Break points.

V A anlise estruturada a melhor maneira de encontrar erros
em programao orientada a objetos.
Esto certos apenas os itens
A) I e II.
B) I e III.
C) II e V.
D) III e IV.
E) IV e V.

Define metas e objetivos dos testes no
escopo da iterao (ou projeto)
Explicita a abordagem adotada, os
recursos necessrios e os produtos
liberados
Determina a estrutura (framework) na
qual os papis de testes funcionaro
Assim como em outros documentos,
necessrio ganhar a aprovao e
aceitao dos envolvidos
Tem a finalidade de identificar e
comunicar as condies especficas
nas quais as funcionalidades sero
testadas
Define um conjunto de:
Entradas de teste
Condies de execuo
Resultados esperados

Descrio do Caso de Teste
Descreve o objetivo e o escopo do teste
Condies de execuo:
Pr-Condies
o estado obrigatrio do sistema antes do incio
do teste
Entradas
Estmulos especficos aplicados durante o teste
Pontos de observao
Observaes especficas a serem feitas

Pontos de Controle
Identifica os pontos em que pode ocorrer mudana
do fluxo de controle
Resultados esperados
Condies observveis esperadas aps a execuo
do teste. Pode incluir resposta positivas e
negativas (erros, falhas, etc.)
Ps-condies
Estado ao qual o sistema deve retornar para
permitir a execuo dos testes subsequentes

necessrio desenvolver casos de teste para
cada cenrio do caso de uso
Cenrio (instncias
do caso de uso):
caminhos que
percorrem o fluxo
bsico, alternativo,
de exceo, etc.

Aps cada caminho possvel do caso de uso
mostrado, possvel identificar cenrios do
caso de uso atravs da combinao do fluxo
bsico com fluxos alternativos
Cenrio 1 Fluxo Bsico
Cenrio 2 Fluxo Bsico Fluxo Alternativo 1
Cenrio 3 Fluxo Bsico Fluxo Alternativo 1 Fluxo Alternativo 2
Cenrio 6 Fluxo Bsico Fluxo Alternativo 3 Fluxo Alternativo 1 Fluxo Alternativo 2

possvel obter casos de teste para
cada cenrio atravs da identificao da
condio especfica que causar a
execuo deste cenrio
Exemplo (fluxo alternativo 3):
Ocorrer esse fluxo de eventos se o valor digitado no
Passo 2 acima, "Digitar o Valor da Retirada" for maior que
o saldo atual da conta. O sistema exibir uma mensagem
de aviso e, depois, retornar ao Passo 2 do fluxo bsico
"Digitar o Valor da Retirada" acima, onde o cliente do
banco poder digitar um novo valor de retirada

Com estas informaes, podemos especificar
alguns casos de teste para o fluxo alternativo
nmero 3
ID de Caso de
Cenrio Condio Resultado Esperado
Teste
Passo 2 - Valor da Retirada > Saldo da Retorna ao Passo 2 do fluxo

TC x Cenrio 4
Conta bsico
Passo 2 - Valor da Retirada < Saldo da No executa o Fluxo Alternativo

TC y Cenrio 4
Conta 3, segue o fluxo bsico
Passo 2 - Valor da Retirada = Saldo da No executa o Fluxo Alternativo

TC z Cenrio 4
Conta 3, segue o fluxo bsico

Na prtica, teramos uma lista de TCs parecida com isso...

SAD/PE (CESPE 2010)
[56] A respeito do plano de teste, um registro do processo de
planejamento de testes de software, assinale a opo correta.
A) O processo de planejamento de testes usualmente descrito em um

plano de testes.
B) Um plano de teste de software um registro da execuo de um caso
de teste de software.
C) A automao de um teste de integrao mais facilmente
empreendida que a de um teste de mdulo.
D) A produo de scripts de teste deve preceder a eventual construo
de casos de teste.
E) Ao se inspecionar o contedo de um plano de testes, devem-se
encontrar, entre outras, as seguintes descries: escopo de testes,
abordagens de teste, recursos para realizao dos testes e
cronograma das atividades de teste a serem realizadas.

[1] - [109] C, [61] E
[2-A] - [13-B] E, [85] E, [75] C, [56] C
[2-B] - [98] E, [97] E
[3] - [73] E, [63-A] E, [63-B] E, [97] C
[4] - [79] C, [57-C] E, [57-D] E, [74] C, [13-C] E
[5] - [85] E, [57-B] E, [57-E] E, [57-A] C, [13-D] E
[6] - [13-A] E, [13-B] E, [83] C, [40-A] E, [40-C] E
[7] - [58] C, [83] E
[8] - [39-D] E, [55-C] E, [43] D
[9] - [101] E, [48] E
[10] - [43] B
[11] - [56] E


Qualidade de Software e Testes PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Qualidade de Software e Testes PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Fernando Pedrosa fpedrosa@gmail.

Fernando Pedrosa Lopes 2

Fernando Pedrosa Lopes 3

Fernando Pedrosa Lopes 4

Fernando Pedrosa Lopes 5

Falta Erro Falha

Fernando Pedrosa Lopes 7

Fernando Pedrosa Lopes 8

Fernando Pedrosa Lopes 9

Fernando Pedrosa Lopes 10

Fernando Pedrosa Lopes 11

Fernando Pedrosa Lopes 12

Fernando Pedrosa Lopes 13

Fernando Pedrosa Lopes 14

a) validao, verificao e teste.

Fernando Pedrosa Lopes 15

Fernando Pedrosa Lopes 16

Fernando Pedrosa Lopes 17

Fernando Pedrosa Lopes 18

Fernando Pedrosa Lopes 20

Fernando Pedrosa Lopes 21

Fernando Pedrosa Lopes 22

Fernando Pedrosa Lopes 24

Fernando Pedrosa Lopes 25

Fernando Pedrosa Lopes 26

Fernando Pedrosa Lopes 27

(TSE - CESPE 2006)

Fernando Pedrosa Lopes 28

(DETRAN - CESPE 2009)

Fernando Pedrosa Lopes 29

Fernando Pedrosa Lopes 31

Fernando Pedrosa Lopes 32

Fernando Pedrosa Lopes 33

Fernando Pedrosa Lopes 34

Fernando Pedrosa Lopes 35

Fernando Pedrosa Lopes 38

Fernando Pedrosa Lopes 39

Fernando Pedrosa Lopes 40

Fernando Pedrosa Lopes 41

Fernando Pedrosa Lopes 42

Fernando Pedrosa Lopes 43

Fernando Pedrosa Lopes 44

(CEF - CESPE 2010)

(CEF - CESPE 2010)

Fernando Pedrosa Lopes 45

(MPOG - ESAF 2008)

Fernando Pedrosa Lopes 46

Fernando Pedrosa Lopes 47

Fernando Pedrosa Lopes 48

Fernando Pedrosa Lopes 49

(CEF - CESPE 2010)

Fernando Pedrosa Lopes 50

(CEF CESPE 2010)

(MPOG - ESAF 2008)

Fernando Pedrosa Lopes 51

Fernando Pedrosa Lopes 53

Fernando Pedrosa Lopes 54

Fernando Pedrosa Lopes 55

Fernando Pedrosa Lopes 56

Fernando Pedrosa Lopes 57

(PETROBRAS - CESGRANRIO 2010)

Fernando Pedrosa Lopes 58

(TRE/MT - CESPE 2010)