Aula07 - Testes de Software PDF

Edited with the trial version of
Foxit Advanced PDF Editor

To remove this notice, visit:
www.foxitsoftware.com/shopping
Aula 07
Tecnologia da Informação p/ Caixa Econômica Federal (tópicos 8,9, 10, 11, 12 e 14)
Professor: Diego Carvalho

Tecnologia da Informação para Caixa Econômica Federal
Curso de Teoria e Exercícios CEF
Prof. Diego Carvalho Aula 07
AULA 07
SUMÁRIO PÁGINA
Apresentação 01
Testes de Software 02
Erro, Falha, Falta e Defeito 04
Exercícios 06
Técnicas, Níveis e Tipos de Testes 07
Exercícios 12
Desenvolvimento Orientado a Testes 18
Exercícios 19
Lista de Exercícios Comentados 20
Gabarito 23
Bem, o edital pegou leve nesse assunto! Cobrou poucos tipos de testes e assuntos básicos!
Portanto, vocês têm uma aula bem pequena para estudar! Boa aula! ;D
Engenharia de Software. Noções sobre: Modelagem de processos, Ciclo de vida do software. Metodologias de desenvolvimento de
software. Processo unificado: disciplinas, fases, papéis e atividades. Metodologias ágeis. Análise e projeto orientados a objetos. UML:
visão geral, modelos e diagramas. Padrões de projeto. Arquitetura em três camadas. Arquitetura orientada a serviços. Métricas e
estimativas de software. Análise por pontos de função. Conceitos básicos e aplicações. Engenharia de requisitos. Conceitos básicos.
Noções sobre: técnicas de elicitação de requisitos, especificação de requisitos e técnicas de validação de requisitos. Prototipação.
Interoperabilidade de sistemas, SOA e Web Services, Padrões XML, XSLT, UDDI, WSDL e Soap. Testes de software: conceitos e
aplicações. Testes unitários, de integração e de aceitação: conceitos e aplicações. Desenvolvimento orientado a testes: conceitos e
aplicações. Gerência de configuração: conceitos e práticas. Uso de ferramentas de gerência de configuração. Controle de defeitos:
conceitos e práticas. Portais corporativos: arquitetura da informação, portlets e RSS. Ferramentas de Gestão de Conteúdos. Modelo
de Acessibilidade do Governo Eletrônico.
01929967110
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 1 de 23

TESTES DE SOFTWARE
O Teste de Software é o processo de executar um software com dois objetivos principais: primeiro,
demonstrar ao desenvolvedor e ao cliente que o software atende aos requisitos especificados;
segundo, descobrir falhas ou defeitos no software que apresente comportamento incorreto, não
desejável ou em não conformidade com sua especificação.
Os testes não podem demonstrar que um software é livre de defeitos ou que ele se comportará
conforme especificado em todas as circunstâncias. É sempre possível que um teste ignorado possa
descobrir mais problemas no sistema. Já dizia Edsger Dijkstra: “Os testes podem somente mostrar
a presença de erros, não sua ausência”.
O que é um Teste de Software? Myers diz que é o processo de executar um determinado software
com a intenção de encontrar defeitos. A IEEE 729 define como o processo formal de avaliar um
sistema ou componente por meios manuais ou automáticos para verificar se ele satisfaz os
requisitos especificados.
O Glossário ISTQB conceitua atividades do ciclo de vida, estáticas ou dinâmicas, voltadas para o
planejamento, preparação e avaliação de produtos de software e produtos de trabalho
relacionados a fim de determinar se eles satisfazem os requisitos especificados e demonstrar que
estão aptos para sua finalidade e detecção de defeitos.
Ao longo de diversos anos, a engenharia de software evoluiu de modo a sugerir alguns princípios
que guiam os testes de software. Vejamos alguns abaixo:
TESTES DEMONSTRAM A PRESENÇA DE DEFEITOS!
Um teste pode demonstrar a presença de defeitos, mas não pode provar que eles não existem.
Ele reduz a probabilidade de que os defeitos permaneçam em um software, mas mesmo se
nenhum defeito for encontrado não quer dizer que esteja perfeito.
01929967110
TESTES EXAUSTIVOS SÃO IMPOSSÍVEIS!
Testar todas as combinações de entradas e pré-condições é inviável, exceto para casos triviais.
Em vez de realizar testes exaustivos, os riscos e prioridades são levados em consideração para
dar foco aos esforços de teste.
TESTE O MAIS BREVE POSSÍVEL!
Os defeitos encontrados nas fases iniciais do processo de desenvolvimento de software são mais
baratos de serem corrigidos do que aqueles encontrados já em fase produção. Há, inclusive,
técnicas de testes antes mesmo da implementação.

AGRUPAM OS DEFEITOS MAIS SENSÍVEIS
Seguindo o Princípio de Pareto, 80% dos defeitos são causados por 20% do código. Ao identificar
essas áreas sensíveis, os testes podem priorizá-las, enquanto ainda procuram por erros nas
demais regiões.
PARADOXO DO PESTICIDA!
Caso os mesmos testes sejam aplicados repetidamente, em determinado momento eles deixam
de ser úteis, ou seja, não conseguem encontrar nenhum novo defeito. Por isso, os testes precisam
ser revisitados com frequência (novos pesticidas).
TESTES DEPENDEM DO CONTEXTO!
Os testes devem ser elaborados de acordo com o contexto de utilização do software. Exemplo:
um sistema bancário deve ser testado de maneira diferente de uma rede social. Assim como
testes de aplicação web têm foco diferente do desktop.
AUSÊNCIA DE DEFEITOS É UMA ILUSÃO!
Identificar e corrigir os problemas de um software não garantem que ele está pronto. Os testes
foram elaborados para identificar todas as possíveis falhas? O sistema atende às necessidades e
expectativas dos usuários? Ou seja, há outros fatores!
Galera, mudando um pouquinho de assunto! Que tal falarmos um pouco sobre a diferença entre
um Analista de Testes e um Testador? Analista de Teste é o responsável por inicialmente identificar
e posteriormente definir os testes necessários, monitorar a abrangência dos testes e avaliar a
qualidade geral obtida ao testar os Itens de Teste-alvo. Este papel é responsável por:
 Identificar os Itens de Teste-alvo a serem avaliados pelo esforço de teste;

01929967110
 Definir os testes apropriados necessários e quaisquer Dados de Teste associados;

 Coletar e gerenciar os Dados de Teste;
 Avaliar o resultado de cada ciclo de teste;
O papel Testador é responsável pelas atividades centrais do esforço de teste, que envolve conduzir
os testes necessários e registrar os resultados desses testes. Isso inclui:
 Identificar a abordagem de implementação mais apropriada para um dado teste;

 Implementar testes individuais;
 Configurar e executar os testes;
 Registrar os resultados e verificar a execução dos testes;
 Analisar erros de execução e recuperar-se deles;

ERRO, FALHA, FALTA E DEFEITO
Vamos falar brevemente sobre esses conceitos? Para tal, vamos utilizar as definições de diversos
autores e instituições! Antes de tudo, vamos começar pelo mais fácil: Defeito e Falta podem ser
considerados sinônimos – não há qualquer diferença entre esses conceitos. Ademais, os nomes em
inglês podem ser úteis: Erro/Error, Falha/Failure, Falta/Fault e Defeito/Defect.
DE ACORDO COM IEEE 610

Ato inconsistente cometido por um indivíduo ao tentar entender uma determinada
DEFEITO informação, resolver um problema ou utilizar um método ou uma ferramenta. Pode ocasionar
a manifestação de erros em um produto.
Manifestação concreta de um defeito. Diferença entre valor obtido e valor esperado, i.e.,
ERRO qualquer estado intermediário incorreto ou resultado inesperado durante a execução de um
programa constitui um erro.
Comportamento operacional do software diferente do esperado pelo usuário. Uma falha pode
FALHA ter sido causada por diversos erros e alguns erros podem nunca causar uma falha. Afetam
diretamente o usuário final da aplicação.
DE ACORDO COM MALDONADO

Incapacidade de algum componente em realizar a função à qual foi projetado.
DEFEITO
Manifestação de uma falha no sistema, causando diferenças das respostas apresentadas com
ERRO as esperadas – nem todas as falhas causarão erros no programa.
Incapacidade de o sistema executar suas funções requeridas dentro das exigências

FALHA especificadas – não existe falha se o programa não tem defeito.
DE ACORDO COM PRESSMAN

Problema de qualidade descoberto antes de o software ser lançado aos usuários finais ou após
DEFEITO outra atividade de um processo de software
Problema de qualidade descoberto após o software ser lançado aos usuários finais ou após
01929967110
ERRO outra atividade de um processo de software.
Incapacidade de o sistema executar suas funções requeridas dentro das exigências

FALHA especificadas – não existe falha se o programa não tem defeito.
DE ACORDO COM SOMMERVILLE

Uma característica do sistema de software que pode levar a um erro de sistema. Por exemplo,
DEFEITO a falha em iniciar uma variável pode levar a um valor errado quando esta for usada.
Um estado errôneo de sistema que pode levá-lo a um comportamento inesperado pelos seus
ERRO usuários.

Um evento que ocorre em algum momento, quando o sistema não fornece um serviço
FALHA conforme esperado por seus usuários.
Defeitos fazem parte do universo físico, i.e., a aplicação propriamente dita. Ademais, são causados
por pessoas. Defeitos podem ocasionar a manifestação de erros, i.e., a construção de um software
diferente do especificado – fazem parte do universo de informação. Por fim, erros podem gerar
falhas como comportamentos inesperados de um software – fazem parte do universo do usuário.
UNIVERSO DO USUÁRIO
UNIVERSO DA INFORMAÇÃO
UNIVERSO FÍSICO
Vamos ver um exemplo? Imaginem que Steve Jobs (R.I.P.) se enganou na construção da lógica do
software do iPod, provocando um loop infinito e causando, por fim, o travamento do dispositivo.
Ora, qual a causa raiz de tudo isso? O defeito na lógica! Qual foi a consequência? O algoritmo
entrou em loop infinito! E o que o usuário percebeu? O travamento do dispositivo!
Vamos ver outro exemplo? Imaginem que um cabo de rede de uma impressora se desconectou
(aqui está o defeito!), provocando uma falha de comunicação entre estações de trabalho e servidor
de rede (aqui está o Erro!) e causando, por fim, a não impressão de arquivos (aqui está a Falha!).
Ficou mais fácil de entender agora?
Galera, percebam que defeitos são observados sob uma perspectiva interna, i.e., código está
incorreto, lógica está inconsistente, funções estão ausentes, há problemas de hardware, etc. Em
contrapartida, falhas são observadas sob uma perspectiva externa, i.e., sob o ponto de vista da
percepção do usuário – travamento do sistema, terminação anormal, tela azul, etc.
01929967110
No meio, nós temos a perspectiva intermediária. Aí, eu pergunto: erros

sempre causarão falhas? Não! No primeiro exemplo, se o usuário não
utilizou a parte da lógica defeituosa, não haverá consequência
observável. Do mesmo modo, caso o usuário não tente imprimir nada
enquanto o cabo estiver desconectado, nenhuma falha se manifestará!
Percebam, então, que Defeitos causam Erros que podem causar Falhas.
Atentem-se para um detalhe importante: quando há uma diferença entre o resultado observado e
o resultado esperado, temos um erro; quando há uma diferença entre o comportamento observado
e o comportamento esperado, temos uma falha! É muito fácil cair em pegadinhas com conceitos
tão parecidos – por favor, não caiam!

(CESPE - 2010 - TRE-BA - Analista Judiciário - Análise de Sistemas) Segundo o IEEE, defeito é um ato
inconsistente cometido por um indivíduo ao tentar entender determinada informação, resolver um
problema ou utilizar um método ou uma ferramenta; erro é o comportamento operacional do software
diferente do esperado pelo usuário, e que pode ter sido causado por diversas falhas; e falha é uma
manifestação concreta de um defeito em um artefato de software, ou seja, é qualquer estado
intermediário incorreto ou resultado inesperado na execução de um programa.
Comentários:
Ato inconsistente cometido por um indivíduo ao tentar resolver um problema? Trata-se de Defeito – basta
imaginar um programador que usa uma lógica de programação errada; Comportamento operacional do
software diferente do esperado pelo usuário? Trata-se de Falha – basta imaginar um usuário fazendo uma
multiplicação em uma calculadora e saindo um resultado errado; Manifestação concreta de um defeito em
um artefato de software, ou seja, é qualquer estado intermediário incorreto? Trata-se Erro – essa eu admito
que é mais complicada de acertar! Por que? Porque ele diz que se trata de uma manifestação concreta! No
entanto, ele também diz que é um estado intermediário, aí fica fácil!
Gabarito: E
(CESPE - 2010 – INMETRO - Analista de Sistemas - D) Na terminologia de testes, uma falta ou defeito é
a causa de um mau funcionamento de um software; uma falha é o resultado incorreto de uma falta ou
defeito; um erro é a diferença entre um resultado computado e um resultado esperado. As falhas são
descobertas por meio de testes, mas é a correção da falta ou do defeito que eliminará a falha.
Comentários:
Perfeito! É isso mesmo...
Gabarito: C
(CESPE - 2013 - TCE-RO - Analista de Informática) No teste de software, defeitos em um produto podem
01929967110
provocar falhas, gerando erros, que são comportamentos inesperados em um software.
Comentários:
Na verdade, defeitos provocam erros, que podem gerar falhas, que são comportamentos inesperados em
um software.
Gabarito: E

TÉCNICAS, NÍVEIS E TIPOS DE TESTES
Agora vamos falar de uma coisa

muito importante! Podemos olhar
para os testes por meio de três
perspectivas diferentes: Técnicas de
Testes, Níveis de Testes e Tipos de
Testes. A Figura 1 apresenta essas
três perspectivas como um plano
cartesiano de três dimensões. Nós
iremos estudar cada uma dela mais
à frente! As Técnicas de Teste de
Software buscam demonstrar como
testar. Já os Níveis de Testes de
Software buscam demonstrar
quando testar.
Figura 1 - Perspectivas de Testes.
Por fim, os Tipos de Testes de Software buscam demonstrar o que testar. Essas três perspectivas
são apresentadas na Figura 2 e serão detalhadas para melhor entendimento.
01929967110
Figura 2 - Perspectivas de Testes.
As Técnicas de Testes se dividem em: Caixa-Branca, Caixa-Preta e Caixa-Cin . A primeira se foca

nas estruturas internas dos procedimentos do sistema. A segunda se foca nas entradas e saídas
especificadas nos requisitos funcionais. Já a terceira se foca tanto em estruturas internas quanto nas
entradas e saídas especificadas nos requisitos.
A Técnica Caixa-Branca (também conhecida como Estrutural ou Orientada à Lógica) analisa

caminhos lógicos possíveis de serem executados, portanto é necessário ter conhecimento sobre o
funcionamento interno dos componentes. Ele busca garantir que todos os caminhos independentes
de um módulo sejam executados pelo menos uma vez.

Além disso, ele trata de todas as decisões lógicas para valores verdadeiros e falsos, além de executar
laços dentro dos valores limites e avaliar as estruturas de dados internas. As técnicas principais são:
Testes de Caminho Básico, Testes de Estruturas de Controle e Complexidade Ciclomática. Vamos
vê-los mais detalhadamente.
 Caminho Básico: permite derivar uma medida de complexidade lógica de um projeto

procedimental e a utiliza para definir um conjunto básico de caminhos de execução.
 Estruturas de Controle: permite validar estruturas de controle como estruturas de condição,

estruturas de fluxo de dados ou estruturas de laços.
 Complexidade Ciclomática: permite medir quantitativamente a complexidade lógica de um

código por meio do número de caminhos independentes.
A Técnica Caixa-Preta (também conhecida como Comportamental, Funcional ou Orientada a Dado)

se baseia em pré e pós-condições, geralmente sendo utilizada nas etapas posteriores da disciplina
de testes. Ele busca funções incorretas ou inexistentes, erros de comportamento ou desempenho,
erros de inicialização e interface, etc.
Ele tem o objetivo de verificar a funcionalidade e aderência aos requisitos, em uma ótica externa
ou do usuário, sem se basear em qualquer conhecimento do código ou lógica interna do
mponente. As técnicas principais são: Testes Baseados em Grafos, Particionamento de
Equivalências, Análise de Valor Limite e Teste de Matriz Ortogonal.
 Baseado em Grafos: permite identificar os objetos e gera grafos para representá-los,

testando-os e seus relacionamentos com o intuito de descobrir erros.
 Partição de Equivalência: permite agrupar os valores de entrada em categorias de dados

para evitar testes redundantes e aumentar a cobertura de testes do sistema.
 Análise de Valor Limite: permite buscar exercitar os limites do domínio de entrada, tendo
em vista que a maioria dos erros se encontram nas extremidades da entrada.
 Matriz Ortogonal: utilizado com entradas relativamente pequenas, casos de testes são
01929967110
espalhados uniformemente pelo domínio do teste para detectar falhas.
Os Níveis de Teste (também conhecido como Estágio/Estratégias) geralmente são agrupados de

acordo com o momento em que eles são executados ou também pelo nível de especificidade do
teste. Exemplos: Teste de Unidade, Teste de Integração, Teste de Sistema, Teste de Aceitação, entre
outros.

Figura 3 - Estágios de Testes.
A Figura 3 mostra que a espiral inicia-se em sentido horário pelo Teste de Unidade (que analisa o
código), em seguida realiza o Teste de Integração (que analisa o projeto), depois o Teste de
Validação ou Aceitação (que analisa os requisitos), e, por fim, o Teste de Sistema (que analisa o
sistema).
TESTE DE UNIDADE
Trata do esforço de verificação na menor unidade de projeto de software – componente ou

módulo de software. Os testes unitários verificam o funcionamento de um pedaço do sistema ou
software isoladamente ou que possam ser testados separadamente. Eles são considerados um
apêndice ao passo de codificação.
O projeto de Teste de Unidade pode ser realizado antes que o código seja iniciado ou depois
de o código-fonte ter sido gerado. Ele enfoca a lógica interna de processamento e as estruturas
de dados dentro dos limites de um componente. Professor, mas que componente é esse? Ora,
métodos, classes ou módulos!
01929967110
TESTE DE INTEGRAÇÃO
Trata do esforço de verificação em uma combinação de componentes para verificar se eles

funcionam corretamente juntos, conforme as especificações. Busca encontrar defeitos nas
interfaces e nas interações entre componentes ou sistemas integrados. Ele sucede o Teste de
Unidade e antecede o Teste de Sistema.
Os resultados do Teste de Unidade dos módulos do sistema servem de insumo para o Teste de
Integração. É uma técnica sistemática para construir a arquitetura de um software e descobrir
erros na integração entre os componentes. Os módulos são integrados gradualmente a fim de
facilitar a localização de erros.

TESTE DE ACEITAÇÃO/VALIDAÇÃO
Trata do esforço em demonstrar a conformidade com os requisitos de software. Focaliza ações

visíveis ao usuário e saídas do sistema reconhecidas também pelo usuário. É bem sucedida
quando o software funciona do modo que pode ser razoavelmente esperado pelo usuário. Ele
sucede o Teste de Integração e antecede o Teste de Sistema.
O ambiente de teste utilizado deve ser o mais próximo possível do ambiente real! Os tipos mais
comuns são o Teste Alfa e o Teste Beta. O primeiro ocorre em um ambiente controlado –
simulando a forma de utilização do usuário. Já o segundo ocorre no ambiente real de utilização
e é realizado pelo próprio usuário.
TESTE DE SISTEMA/FUNCIONAL
Trata do esforço em demonstrar o funcionamento do sistema como um todo, dentro de um

ambiente operacional controlado, para validar a exatidão e perfeição na execução de suas
funções. Utilizam-se dados de teste a fim de tentar evitar a ocorrência de defeitos em ambiente
de produção.
Lembremos que um software frequentemente é apenas um elemento de um sistema maior. Logo

é necessário testá-lo considerando o contexto em que será utilizado. Eles são conduzidos em
um ambiente completo e integrado, por várias pessoas (não só os desenvolvedores). Busca-se
exercitar o sistema por completo!
Por fim, vamos tratar dos Tipos de Testes. Exemplos: Teste de Regressão, Fumaça, Recuperação,
Segurança, Carga, Desempenho e Usabilidade. Veremos alguns aqui:
TESTE DE CARGA/ESTRESSE/VOLUME
Trata do esforço em demonstrar o funcionamento do software em situações anormais, i.e.,

executa o sistema em condições incomuns de demanda de recursos, velocidade, frequência e
01929967110
volume. Em outras palavras, verifica qual limite de dados processados até a falha do sistema.
TESTE DE DESEMPENHO/PERFORMANCE
Trata do esforço em demonstrar que o sistema atende aos níveis de desempenho e tempo de
resposta acordados com os usuários e definidos nos requisitos. Geralmente ocorre paralelamente
ao Teste de Carga e avalia a capacidade de resposta do sistema em determinadas configurações.
TESTE DE VULNERABILIDADE

Trata do esforço em demonstrar buracos de segurança e vulnerabilidades podem ser aplicadas
à rede/máquina alvo. Quem efetuar o teste vai tentar identificar nas máquinas na rede alvo todas
as portas abertas, sistemas operativos e aplicações a serem executadas.
TESTE DE USABILIDADE
Trata do esforço em demonstrar falhas na facilidade de uso do software pelos usuários finais.
Enfatiza fatores humanos, consistência na interface gráfica, estética, ajuda online, assistentes
wizard, documentação do usuário, material de treinamento, entre outros. Uma boa interface com
o usuário deve ser fácil de usar e entender.
01929967110

(CESPE - 2013 - MPU - Técnico - Tecnologia da Informação e Comunicação) Um dos critérios do teste
de unidade é o particionamento de equivalência, que consiste no particionamento do domínio de
entrada do programa de modo que o conjunto de testes resultantes corresponda a uma representação
satisfatória de todo o domínio.
Comentários:
Vamos lá? Particionamento de Equivalência é um dos critérios de Teste Caixa-Preta e, não, Teste de Unidade!
Gabarito: E
(CESPE - 2013 - TCE-RO - Analista de Informática) Os principais níveis de teste de software são os de
caixa branca, os de caixa preta, os de sistema e os de aceitação.
Comentários:
Testes Caixa-Branca e Caixa-Preta não são Níveis de Testes, mas Técnicas de Testes.
Gabarito: E
(CESPE - 2013 - INPI - Analista de Planejamento - Desenvolvimento e Manutenção de Sistemas) Na

disciplina de testes, a implementação de testes, a execução do conjunto de testes e a análise das falhas
de testes são atividades de responsabilidade do analista de testes.
Comentários:
Na verdade, todas essas atividades fazem parte do rol de responsabilidades do Testador e, não, do Analista
de Testes.
Gabarito: E
01929967110
(CESPE - 2013 - INPI - Analista de Planejamento - Desenvolvimento e Manutenção de Sistemas) No teste

de integração, verificam-se o funcionamento em conjunto dos componentes do sistema, se são
chamados corretamente e se a transferência de dados acontece no tempo correto, por meio de suas
interfaces.
Comentários:
Perfeito, é isso mesmo!
Gabarito: C
(FCC - 2013 - DPE-SP - Agente de Defensoria - Analista de Sistemas - A) O teste de software constitui-
se em uma etapa importante no ciclo de desenvolvimento de software. Uma das características mais

importantes de um conjunto de testes de software, adequadamente planejados, é provar a correção
integral no programa sob teste.
Comentários:
Qual é o objetivo de um teste? Encontrar erros! Nós já sabemos que é virtualmente impossível provar a
correção integral de um programa.
Gabarito: E
(FCC - 2013 - DPE-SP - Agente de Defensoria - Analista de Sistemas - B) O teste de software constitui-
importantes de um conjunto de testes de software, adequadamente planejados, é ter alta probabilidade
de detectar erros no programa sob teste.
Comentários:
Exatamente isso! Um teste deve ter alta probabilidade de encontrar erros.
Gabarito: C
10. (FCC - 2013 - DPE-SP - Agente de Defensoria - Analista de Sistemas - C) O teste de software constitui-
importantes de um conjunto de testes de software, adequadamente planejados, é ter grande
redundância, a fim de testar mais de uma vez cada linha do programa sob teste.
Comentários:
Opaaaa... não são desejáveis testes redundantes, mas – sim – eficientes.
Gabarito: E
(FCC - 2013 - DPE-SP - Agente de Defensoria - Analista de Sistemas - D) O teste de software constitui-
importantes de um conjunto de testes de software, adequadamente planejados, é ser de alta
complexidade, pois assim pode-se cobrir todo o programa sob teste com apenas um teste.
01929967110
Comentários:
Na verdade, testes não devem ser muito simples nem muito complexos.
Gabarito: E
12. (FCC - 2013 - DPE-SP - Agente de Defensoria - Analista de Sistemas - E) O teste de software constitui-
importantes de um conjunto de testes de software, adequadamente planejados, é ser ocultado da equipe
de desenvolvimento do software, pois esta pode querer impedir sua aplicação.
Comentários:
Não faz nenhum sentido – inclusive, a própria Equipe de Desenvolvimento realiza testes (Testes de Unidade).

Gabarito: E
13. (FCC - 2012 - TCE- - Analista de Controle Externo - Tecnologia da Informação - I) Uma estratégia de
teste que é escolhida por grande parte das equipes de software adota uma visão incremental do teste,
começando com o teste de unidades individuais de programa, avançando para testes projetados a fim
de facilitar a integração das unidades e culmina com testes que exercitam o sistema construído.
Comentários:
É isso mesmo! Inicia-se com Testes de Unidade, depois Testes de Integração e, por fim, Testes de Sistema.
Gabarito: C
14. (FCC - 2012 - TCE-AM - Analista de Controle Externo - Tecnologia da Informação - II) O teste de unidade
focaliza o esforço de verificação na menor unidade de projeto do software - o componente ou módulo
de software. Usando a descrição de projeto no nível de componente como guia, caminhos de controle
importantes são testados para descobrir erros dentro dos limites do módulo.
Comentários:
Essa é uma boa definição para Testes de Unidade. Perfeito!

Gabarito: C
15. (FCC - 2012 - TCE-AM - Analista de Controle Externo - Tecnologia da Informação - O teste de unidade
é normalmente considerado um apêndice ao passo de codificação. O projeto de teste de unidade pode
ser realizado antes que o código seja iniciado ou depois de o código-fonte ter sido gerado.
Comentários:
É exatamente isso! É comum – inclusive – que frameworks utilizem o Test-first Design.
Gabarito: C
16. (FCC - 2012 - TCE-AM - Analista de Controle Externo - Tecnologia da Informação - IV) O teste de
integração é uma técnica sistemática para construir a arquitetura do software enquanto, ao mesmo
tempo, conduz testes para descobrir erros associados às interfaces. O objetivo é, a partir de componentes
01929967110
testados no nível de unidade, construir uma estrutura de programa determinada pelo projeto.
Comentários:
Essa é a perfeita definição de Teste de Integração.
Gabarito: C
17. (FCC - 2012 - - 6ª Região (PE) - Analista Judiciário - Tecnologia da Informação - I) Testes de cenário
são úteis pois podem garantir que não restam erros no sistema. Neste ponto diferem dos testes de
componentes que apenas garantem a integridade de módulos isolados do sistema, mas não garantem
que a totalidade do sistema está isenta de erros.
Comentários:

Como já vimos, nenhum teste é capaz de garantir que não restam erros em um sistema.
Gabarito: E
18. (FCC - 2012 - TRT - 6ª Região (PE) - Analista Judiciário - Tecnologia da Informação - C) Um teste bem
sucedido é um teste que não encontra nenhum erro no software.
Comentários:
Bem, essa é até engraçada! Geralmente, um teste bem sucedido é aquele que encontra erros! Se ele não
encontra erros, é mais provável que o teste tenha sido mal feito.
Gabarito: E
19. (FCC - 2011 - TCE-PR - Analista de Controle – Informática - A) Testes de desempenho devem ser
produzidos de forma a garantir que o sistema possa processar a sua carga prevista, sendo que tais testes
geralmente são planejados para que a carga seja continuamente aumentada até que o sistema apresente
desempenho fora do aceitável.
Comentários:
Os testes de desempenho devem ser projetados para assegurar que o sistema pode operar na carga
necessária. Isso envolve, geralmente, o planejamento de uma série de testes em que a carga é
constantemente aumentada até que o desempenho se torne inaceitável. Perfeito!
Gabarito: C
20. (FCC - 2011 - TCE-PR - Analista de Controle – Informática - B) Os testes de desempenho devem
determinar se um sistema corresponde às suas exigências, sendo que a descoberta de defeitos ou
problemas no sistema não é enfoque desta etapa.
Comentários:
O teste de desempenho concentra-se tanto em demonstrar que o sistema atende aos requisitos como
também em descobrir problemas e defeitos no sistema.
01929967110
Gabarito: E
21. (FCC - 2011 - TRE-PE - Analista Judiciário - Análise de Sistemas - B) Testes sempre podem mostrar a
ausência de erros.
Comentários:
Já vimos um milhão de vezes! Testes não garantem a ausência de erros!
Gabarito: E

22. (FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento e Manutenção - II) O teste de unidade
focaliza o esforço de verificação na maior unidade de projeto do software: o componente ou módulo de
software.
Comentários:
Opa... como é? Maior unidade de projeto? Não! Na menor unidade de projeto do software!
Gabarito: E
23. (FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento e Manutenção - III) O teste de unidade
enfoca a lógica interna de processamento e as estruturas de dados dentro dos limites de um
componente.
Comentários:
Perfeito! É exatamente isso!
Gabarito: C
24. (FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento e Manutenção - IV) No teste de
unidade, a interface do módulo é testada para garantir que a informação flui adequadamente para
dentro e para fora da unidade de programa que está sendo testada.
Comentários:
Galera, não se exaltem! O Teste de Integração é o que mais testa a interface, porém o Teste de Unidade
também a testa. Não há nada errado aqui!
Gabarito: C
25. (FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento e Manutenção - IV) Na direção dos
tipos de teste focados pela engenharia de software, os testes de integração cuidam dos tópicos
associados com os problemas de verificação o projeto de software.
Comentários:
01929967110
Exatamente isso! Vamos relembrar? Testes de Unidade tratam do código-fonte; Testes de Integração tratam
de Projeto de Software; Testes de Validação tratam de Requisitos; Testes de Sistema tratam de Engenharia
de Sistemas.
Gabarito: C
26. (FCC - 2010 - TRT - 20ª REGIÃO (SE) - Analista Judiciário - Tecnologia da Informação - C) No contexto
da estratégia para o teste de um projeto, os estágios de teste desempenham um papel importante. O
teste que é aplicado a componentes do modelo de implementação para verificar se os fluxos de controle
e de dados estão cobertos e funcionam conforme o esperado, é o teste de integração.
Comentários:

Bem, apesar de falar sobre componentes do modelo de implementação, não se trata de Teste de Integração.
Observem que trata de um nível de abstração bastante baixo, sobre os fluxos de controle e de dados.
Portanto, trata-se de um Teste de Unidade.
Gabarito: E
27. (FCC - - TRE-PI - Técnico Judiciário - Programação de Sistemas - C) Também conhecido por teste
estrutural ou orientado à lógica, é uma técnica de teste de software que trabalha diretamente sobre o
código fonte do componente de software para avaliar aspectos, tais como, teste de condição, teste de
fluxo de dados, teste de ciclos e teste de caminhos lógicos. Trata-se da técnica de teste da Caixa-preta.
Comentários:
Não! Isso se trata do Teste Caixa-Branca.
Gabarito: E
28. (FCC - - SEFAZ-SP - Agente Fiscal de Rendas - Tecnologia da Informação - Prova 3 - B) Garantir
que um ou mais componentes de um sistema combinados funcionam corretamente é o objetivo do tipo
de teste de integração.
Comentários:
Perfeito! É bem intuitivo!
Gabarito: C
29. (FCC - - TRT - 18ª Região (GO) - Analista Judiciário - Tecnologia da Informação - A) Uma sistemática
para construção da arquitetura do software enquanto, ao mesmo tempo, conduz ao descobrimento de
erros associados às interfaces é a estratégia de teste de software denominada de sistema.
Comentários:
Opa... na verdade, trata-se de Teste de Integração.
Gabarito: E
01929967110

DESENVOLVIMENTO ORIENTADO A TESTES
O Desenvolvimento Orientado a Testes é um método ágil de desenvolvimento de software que se

baseia na repetição de um ciclo de desenvolvimento curto, focado em testes unitários, em que os
casos de teste que verificam uma nova funcionalidade é escrito antes mesmo da própria
funcionalidade. Escreve-se o teste, encontre uma falha e refatore-o, ciclicamente.
Portanto, implementa-se um caso de teste automatizado, em seguida implementa-se a

funcionalidade para que, então, ela seja testada em relação ao caso de teste desenvolvido. Assim,
defeitos são encontrados e componentes são refatorados para atender às mudanças. Ok, professor!
Mas o que acontece depois?
Nesta abordagem, implementa-se na funcionalidade apenas o que é necessário para passar no

teste, assim desenvolvem-se minúsculos incrementos de código a cada ciclo, estimulando um
projeto simples. Lembram-se que essa é uma prática do XP assim como o Desenvolvimento Test-
first e Refatoração? Pois é, TDD se origina do XP!
IMPORTANTE
Esse processo de desenvolvimento de software não é uma abordagem para realizar testes, mas uma abordagem
para desenvolver softwares.
01929967110
Figura 1 - Ciclo de Desenvolvimento do TDD.

30. (CESPE – – INMETRO – Analista Executivo em Metrologia e Qualidade – Desenvolvimento de

Sistemas) A rotina diária dos desenvolvedores, ao empregar processos baseados no TDD (Test-Driven
Development), é concentrada na elaboração de testes de homologação.
Comentários:
A rotina dos desenvolvedores é concentrada, na verdade, na elaboração de testes unitários e, não, de

homogação. Lembrem-se: constrói o teste unitário, constrói a funcionalidade e refatora a funcionalidade.
Gabarito: E
31. (CESPE – 2013 – INPI – Analista de Planejamento – Desenvolvimento e Manutenção de Sistemas) Usando-
se o TDD, as funcionalidades devem estar completas e da forma como serão apresentadas aos seus
usuários para que possam ser testadas e consideradas corretas.
Comentários:
Pelo contrário, primeiro são feitos os testes e depois desenvolvem-se as funcionalidades.
Gabarito: E
01929967110

LISTA DE EXERCÍCIOS COMENTADOS
(CESPE - 2010 - TRE-BA - Analista Judiciário - Análise de Sistemas) Segundo o IEEE, defeito é um ato
inconsistente cometido por um indivíduo ao tentar entender determinada informação, resolver um
problema ou utilizar um método ou uma ferramenta; erro é o comportamento operacional do software
diferente do esperado pelo usuário, e que pode ter sido causado por diversas falhas; e falha é uma
manifestação concreta de um defeito em um artefato de software, ou seja, é qualquer estado
intermediário incorreto ou resultado inesperado na execução de um programa.
(CESPE - 2010 – INMETRO - Analista de Sistemas - D) Na terminologia de testes, uma falta ou defeito é
a causa de um mau funcionamento de um software; uma falha é o resultado incorreto de uma falta ou
defeito; um erro é a diferença entre um resultado computado e um resultado esperado. As falhas são
descobertas por meio de testes, mas é a correção da falta ou do defeito que eliminará a falha.
(CESPE - 2013 - TCE-RO - Analista de Informática) No teste de software, defeitos em um produto podem
provocar falhas, gerando erros, que são comportamentos inesperados em um software.
(CESPE - 2013 - MPU - Técnico - Tecnologia da Informação e Comunicação) Um dos critérios do teste
de unidade é o particionamento de equivalência, que consiste no particionamento do domínio de
entrada do programa de modo que o conjunto de testes resultantes corresponda a uma representação
satisfatória de todo o domínio.
(CESPE - 2013 - TCE-RO - Analista de Informática) Os principais níveis de teste de software são os de
caixa branca, os de caixa preta, os de sistema e os de aceitação.
(CESPE - 2013 - INPI - Analista de Planejamento - Desenvolvimento e Manutenção de Sistemas) Na

disciplina de testes, a implementação de testes, a execução do conjunto de testes e a análise das falhas
de testes são atividades de responsabilidade do analista de testes.
(CESPE - 2013 - INPI - Analista de Planejamento - Desenvolvimento e Manutenção de Sistemas) No teste

de integração, verificam-se o funcionamento em conjunto dos componentes do sistema, se são
chamados corretamente e se a transferência de dados acontece no tempo correto, por meio de suas
interfaces.
01929967110
(FCC - 2013 - DPE-SP - Agente de Defensoria - Analista de Sistemas - A) O teste de software constitui-
importantes de um conjunto de testes de software, adequadamente planejados, é provar a correção
integral no programa sob teste.
(FCC - 2013 - DPE-SP - Agente de Defensoria - Analista de Sistemas - B) O teste de software constitui-
importantes de um conjunto de testes de software, adequadamente planejados, é ter alta probabilidade
de detectar erros no programa sob teste.
10. (FCC - 2013 - DPE-SP - Agente de Defensoria - Analista de Sistemas - C) O teste de software constitui-

importantes de um conjunto de testes de software, adequadamente planejados, é ter grande
redundância, a fim de testar mais de uma vez cada linha do programa sob teste.
(FCC - 2013 - DPE-SP - Agente de Defensoria - Analista de Sistemas - D) O teste de software constitui-
importantes de um conjunto de testes de software, adequadamente planejados, é ser de alta
complexidade, pois assim pode-se cobrir todo o programa sob teste com apenas um teste.
12. (FCC - 2013 - DPE-SP - Agente de Defensoria - Analista de Sistemas - E) O teste de software constitui-
importantes de um conjunto de testes de software, adequadamente planejados, é ser ocultado da equipe
de desenvolvimento do software, pois esta pode querer impedir sua aplicação.
13. (FCC - 2012 - TCE- - Analista de Controle Externo - Tecnologia da Informação - I) Uma estratégia de
teste que é escolhida por grande parte das equipes de software adota uma visão incremental do teste,
começando com o teste de unidades individuais de programa, avançando para testes projetados a fim
de facilitar a integração das unidades e culmina com testes que exercitam o sistema construído.
14. (FCC - 2012 - TCE-AM - Analista de Controle Externo - Tecnologia da Informação - II) O teste de unidade
focaliza o esforço de verificação na menor unidade de projeto do software - o componente ou módulo
de software. Usando a descrição de projeto no nível de componente como guia, caminhos de controle
importantes são testados para descobrir erros dentro dos limites do módulo.
15. (FCC - 2012 - TCE-AM - Analista de Controle Externo - Tecnologia da Informação - O teste de unidade
é normalmente considerado um apêndice ao passo de codificação. O projeto de teste de unidade pode
ser realizado antes que o código seja iniciado ou depois de o código-fonte ter sido gerado.
16. (FCC - 2012 - TCE-AM - Analista de Controle Externo - Tecnologia da Informação - IV) O teste de
integração é uma técnica sistemática para construir a arquitetura do software enquanto, ao mesmo
tempo, conduz testes para descobrir erros associados às interfaces. O objetivo é, a partir de componentes
testados no nível de unidade, construir uma estrutura de programa determinada pelo projeto.
17. (FCC - 2012 - TRT - 6ª Região (PE) - Analista Judiciário - Tecnologia da Informação - I) Testes de cenário
são úteis pois podem garantir que não restam erros no sistema. Neste ponto diferem dos testes de
componentes que apenas garantem a integridade de módulos isolados do sistema, mas não garantem
que a totalidade do sistema está isenta de erros.
01929967110
18. (FCC - 2012 - TRT - 6ª Região (PE) - Analista Judiciário - Tecnologia da Informação - C) Um teste bem
sucedido é um teste que não encontra nenhum erro no software.
19. (FCC - 2011 - TCE-PR - Analista de Controle – Informática - A) Testes de desempenho devem ser
produzidos de forma a garantir que o sistema possa processar a sua carga prevista, sendo que tais testes
geralmente são planejados para que a carga seja continuamente aumentada até que o sistema apresente
desempenho fora do aceitável.
20. (FCC - 2011 - TCE-PR - Analista de Controle – Informática - B) Os testes de desempenho devem
determinar se um sistema corresponde às suas exigências, sendo que a descoberta de defeitos ou
problemas no sistema não é enfoque desta etapa.

21. (FCC - 2011 - TRE-PE - Analista Judiciário - Análise de Sistemas - B) Testes sempre podem mostrar a
ausência de erros.
22. (FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento e Manutenção - II) O teste de unidade
focaliza o esforço de verificação na maior unidade de projeto do software: o componente ou módulo de
software.
23. (FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento e Manutenção - III) O teste de unidade
enfoca a lógica interna de processamento e as estruturas de dados dentro dos limites de um
componente.
24. (FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento e Manutenção - IV) No teste de
unidade, a interface do módulo é testada para garantir que a informação flui adequadamente para
dentro e para fora da unidade de programa que está sendo testada.
25. (FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento e Manutenção - IV) Na direção dos
tipos de teste focados pela engenharia de software, os testes de integração cuidam dos tópicos
associados com os problemas de verificação o projeto de software.
26. (FCC - 2010 - TRT - 20ª REGIÃO (SE) - Analista Judiciário - Tecnologia da Informação - C) No contexto
da estratégia para o teste de um projeto, os estágios de teste desempenham um papel importante. O
teste que é aplicado a componentes do modelo de implementação para verificar se os fluxos de controle
e de dados estão cobertos e funcionam conforme o esperado, é o teste de integração.
27. (FCC - - TRE-PI - Técnico Judiciário - Programação de Sistemas - C) Também conhecido por teste
estrutural ou orientado à lógica, é uma técnica de teste de software que trabalha diretamente sobre o
código fonte do componente de software para avaliar aspectos, tais como, teste de condição, teste de
fluxo de dados, teste de ciclos e teste de caminhos lógicos. Trata-se da técnica de teste da Caixa-preta.
28. (FCC - - SEFAZ-SP - Agente Fiscal de Rendas - Tecnologia da Informação - Prova 3 - B) Garantir
que um ou mais componentes de um sistema combinados funcionam corretamente é o objetivo do tipo
de teste de integração.
29. (FCC - - TRT - 18ª Região (GO) - Analista Judiciário - Tecnologia da Informação - A) Uma sistemática
para construção da arquitetura do software enquanto, ao mesmo tempo, conduz ao descobrimento de
erros associados às interfaces é a estratégia de teste de software denominada de sistema.
01929967110
30. (CESPE – – INMETRO – Analista Executivo em Metrologia e Qualidade – Desenvolvimento de

Sistemas) A rotina diária dos desenvolvedores, ao empregar processos baseados no TDD (Test-Driven
Development), é concentrada na elaboração de testes de homologação.
31. (CESPE – 2013 – INPI – Analista de Planejamento – Desenvolvimento e Manutenção de Sistemas) Usando-
se o TDD, as funcionalidades devem estar completas e da forma como serão apresentadas aos seus
usuários para que possam ser testadas e consideradas corretas.

1 2 3 4 5 6 7 8 9 10
E C E E E E C E C E
11 12 13 14 15 16 17 18 19 20
E E C C C C E E C E
21 22 23 24 25 26 27 28 29 30
E E C C C E E C E E
31 32 33 34 35 36 37 38 39 40
E - - - - - - - - -
01929967110

Aula07 - Testes de Software PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula07 - Testes de Software PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Edited with the trial version of

Foxit Advanced PDF Editor

Professor: Diego Carvalho

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 1 de 23

TESTES DEMONSTRAM A PRESENÇA DE DEFEITOS!

TESTES EXAUSTIVOS SÃO IMPOSSÍVEIS!

TESTE O MAIS BREVE POSSÍVEL!

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 2 de 23

TESTES DEPENDEM DO CONTEXTO!

AUSÊNCIA DE DEFEITOS É UMA ILUSÃO!

 Identificar os Itens de Teste-alvo a serem avaliados pelo esforço de teste;

 Definir os testes apropriados necessários e quaisquer Dados de Teste associados;

 Identificar a abordagem de implementação mais apropriada para um dado teste;

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 3 de 23

ERRO, FALHA, FALTA E DEFEITO

DE ACORDO COM IEEE 610

DE ACORDO COM MALDONADO

Incapacidade de o sistema executar suas funções requeridas dentro das exigências

DE ACORDO COM PRESSMAN

ERRO outra atividade de um processo de software.

Incapacidade de o sistema executar suas funções requeridas dentro das exigências

DE ACORDO COM SOMMERVILLE

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 4 de 23

No meio, nós temos a perspectiva intermediária. Aí, eu pergunto: erros

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 5 de 23

Perfeito! É isso mesmo...

provocar falhas, gerando erros, que são comportamentos inesperados em um software.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 6 de 23

TÉCNICAS, NÍVEIS E TIPOS DE TESTES

Agora vamos falar de uma coisa

Figura 1 - Perspectivas de Testes.

Figura 2 - Perspectivas de Testes.

As Técnicas de Testes se dividem em: Caixa-Branca, Caixa-Preta e Caixa-Cin . A primeira se foca

A Técnica Caixa-Branca (também conhecida como Estrutural ou Orientada à Lógica) analisa

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 7 de 23

 Caminho Básico: permite derivar uma medida de complexidade lógica de um projeto

 Estruturas de Controle: permite validar estruturas de controle como estruturas de condição,

 Complexidade Ciclomática: permite medir quantitativamente a complexidade lógica de um

A Técnica Caixa-Preta (também conhecida como Comportamental, Funcional ou Orientada a Dado)

 Baseado em Grafos: permite identificar os objetos e gera grafos para representá-los,

 Partição de Equivalência: permite agrupar os valores de entrada em categorias de dados

espalhados uniformemente pelo domínio do teste para detectar falhas.

Os Níveis de Teste (também conhecido como Estágio/Estratégias) geralmente são agrupados de

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 8 de 23

Figura 3 - Estágios de Testes.

Trata do esforço de verificação na menor unidade de projeto de software – componente ou

Trata do esforço de verificação em uma combinação de componentes para verificar se eles

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 9 de 23

Trata do esforço em demonstrar a conformidade com os requisitos de software. Focaliza ações

Trata do esforço em demonstrar o funcionamento do sistema como um todo, dentro de um

Lembremos que um software frequentemente é apenas um elemento de um sistema maior. Logo

Trata do esforço em demonstrar o funcionamento do software em situações anormais, i.e.,

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 10 de 23

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 11 de 23

(CESPE - 2013 - INPI - Analista de Planejamento - Desenvolvimento e Manutenção de Sistemas) Na

(CESPE - 2013 - INPI - Analista de Planejamento - Desenvolvimento e Manutenção de Sistemas) No teste

Perfeito, é isso mesmo!

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 12 de 23

Exatamente isso! Um teste deve ter alta probabilidade de encontrar erros.

Opaaaa... não são desejáveis testes redundantes, mas – sim – eficientes.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 13 de 23

Essa é uma boa definição para Testes de Unidade. Perfeito!

É exatamente isso! É comum – inclusive – que frameworks utilizem o Test-first Design.