Você está na página 1de 144

Aula 08

Engenharia de Software para Concursos - Curso Regular


Professor: Diego Carvalho
Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

AULA 08

SUMÁRIO PÁGINA
Apresentação 01
- Qualidade de Software 03
- Verificação & Validação 10
- Erro, Falta, Falha e Defeito 18
- Testes de Software 24
Lista de Exercícios Comentados 111
Gabarito 142

16712855225

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


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Engenharia de Software. Conceitos Básicos ou Gerais. Ciclo de vida do software. Modelos,


Metodologias ou Processos de Desenvolvimento de Software: Modelo em Cascata. Modelo Orientado
a Reuso. Modelo em Prototipagem, Modelo Evolucionário, Modelo Espiral, Modelo Formal, RAD, Modelo
Iterativo e Incremental. Processo Unificado: Conceitos Básicos, Dimensões Dinâmica, Estática e
Prática, Gráfico das Baleias, Fases (Iniciação, Elaboração, Construção e Transição), Disciplinas ou
Fluxo de Processos (Modelagem de Negócio, Requisitos, Análise e Projeto, Implementação, Teste,
Implantação, Gestão de Configuração e Mudança, Gestão de Projetos, Ambiente), Artefatos,
Atividades, Melhores Práticas, Principais Marcos, Princípios Chaves. Metodologias Ágeis de
Desenvolvimento de Software: Scrum, eXtreme Programming (XP), Feature-driven Development
(FDD), Test-driven Development (TDD), Acceptance Test-driven Development (ATDD), Kanban.
Definição de Requisito, Classificação de Requisitos (Funcional, Não- Funcional, Domínio; Produto,
Organizacional, Externo; Confiabilidade, Proteção, Desempenho, etc); Engenharia de Requisitos:
Estudo de Viabilidade, Elicitação e Análise de Requisitos, Especificação de Requisitos, Validação de
Requisitos, Gestão de Requisitos. Técnicas de Elicitação e Técnicas de Validação. Linguagem de
Modelagem: Unified Modeling Language (UML) 2.x – Contexto Histórico, Conceitos Básicos, Tipos de
Diagramas (Estruturais, Comportamentais, Interação). Diagramas de Classes, Componentes,
Implantação, Perfil, Objetos, Estrutura Composta, Pacotes, Máquina de Estados, Casos de Uso,
Atividades, Sequência, Comunicação, Interação Geral e Tempo. Conceitos Básicos do Paradigma
Estruturado. Conceitos Básicos de Orientação a Objetos: Classes, Objetos, Atributos, Métodos,
Mensagens, Abstração, Encapsulamento, Polimorfismo, Herança, Relacionamentos). Análise e
Projeto: Conceitos Básicos, Diferenças, Modelos, Classes de Fronteira, Controle e Entidade. Análise
de Pontos de Função: IFPUG – Definição e Contexto, Benefícios e Vantagens, Componentes de Dados
(AIE, ALI) e Transação (EE, SE, CE), Etapas do Procedimento de Contagem: Determinar Tipo de
Contagem, Determinar Escopo e Fronteira, Cálculo dos Pontos de Função Não-Ajustados, Cálculo do
Fator de Ajuste, Cálculo dos Pontos de Função Ajustados. NESMA - Tipos de Contagem e Deflatores.
Qualidade de Software: Garantia e Controle, Principais Características, Verificação & Validação,
Erro, Falha, Falta e Defeito. Testes de Software: Conceitos Básicos, Processo de Testes, Técnicas de
Testes (Teste Caixa Banca, Cinza e Preta), Níveis de Testes (Teste de Unidade, Módulo, Componente;
16712855225

Teste de Integração; Teste de Aceitação, Validação, Release; Teste de Sistema/Funcional). Tipos de


Testes: Carga, Estresse, Volume, Desempenho, Usabilidade, Cenários, Regressão, Back-to-Back,
Comparação, Recuperação, Alfa, Beta, Compatibilidade, Estático, Dinâmico). Arquitetura de
Software. Arquitetura em Camadas (Cliente/Servidor). Arquitetura MVC. Arquitetura Distribuída.
Arquitetura Hub. Arquitetura Microsserviços. Arquitetura Mainframe. Arquitetura Orientada a
Serviços (SOA): Conceitos Básicos, SOAP, WSDL, UDDI. REST. WS-Security. Interoperabilidade de
Sistemas. e- PING: Conceitos Básicos, Interoperabilidade, Escopo, Políticas Gerais, Segmentação,
Gestão. Acessibilidade de Sistemas. e-MAG 3.1: Conceitos Básicos, Acessibilidade, Acesso, Passos
para um Sítio Acessível, Segmentos, Recomendações. Engenharia de Usabilidade. Gerenciamento
Eletrônico de Documentos (GED). Portais Corporativos e Colaborativos.

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


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

QUALIDADE DE SOFTWARE

A qualidade de software tem se aprimorado significativamente nos últimos 15 anos.


Uma razão para isso é o fato de as empresas terem adotado novas técnicas e
tecnologias. Além disso, contudo, tem havido uma conscientização maior da
importância do gerenciamento de qualidade de software e da adoção de técnicas
de gerenciamento de qualidade provenientes da manufatura de software.

Entretanto, qualidade de software é um conceito complexo que não é diretamente


comparável com a qualidade na manufatura. Na manufatura, a noção de qualidade
tem sido aquela em que o produto desenvolvido deve atender às suas
especificações. Em um mundo ideal essa definição deveria ser aplicada a todos os
produtos, mas, para sistemas de software, existem diversos problemas!

Algumas pessoas acham que a qualidade pode ser conseguida definindo-se


padrões e procedimentos de qualidade organizacionais que verifiquem se esses
padrões são seguidos pela equipe de desenvolvimento de software. Seu argumento
é que os padrões devem englobar boas práticas; seguir essas boas práticas
inevitavelmente conduz a produtos de alta qualidade.

Na prática, entretanto, acredito que há muito mais gerenciamento de qualidade do


que padrões e burocracia associada para assegurar que estes foram seguidos. O
gerenciamento de qualidade de software para sistemas de grande porte pode ser
estruturado em três atividades principais:

1. Garantia de qualidade: estabelecimento de um framework de procedimentos


organizacionais e padrões que conduzem a um software de alta qualidade.
16712855225

2. Planejamento de qualidade: seleção de procedimentos e padrões apropriados


deste framework, adaptados para um projeto de software específico.

3. Controle de qualidade: definição e aprovação de processos que assegurem que


a equipe de desenvolvimento tenha seguido os procedimentos e os padrões.

Mas, espera um pouco! Galera, o que é qualidade? A qualidade é algo pelo qual nos
esforçamos para obter nos produtos, processos e serviços. O dicionário diz:

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


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Uma característica inerente ou diferenciada; uma propriedade. b. Um traço


pessoal, especialmente um traço de caráter. 2. Caráter essencial; natureza. 3.a.
Superioridade de natureza. b. Grau ou classificação de excelência.

A qualidade não é um atributo ou uma característica singular. É multidimensional e


pode ser possuída por um produto ou por um processo. A qualidade do produto
está concentrada na criação do produto certo, enquanto a qualidade do processo
está concentrada na criação correta do produto. A definição do dicionário é muito
genérica, vamos ver a definição do processo unificado:

Qualidade é a característica de ter demonstrado a realização da criação de um


produto que atende ou excede os requisitos acordados, conforme avaliado por
medidas e critérios acordados, e que é criado em um processo acordado.

Obter qualidade não é só "atender a requisitos" ou produzir um produto que atende


às necessidades e expectativas dos usuários. Pelo contrário, também inclui a
identificação das medidas e dos critérios para demonstrar a obtenção da qualidade
e a implementação de um processo para garantir que o produto por ele criado
tenha atingido o grau desejado de qualidade e possa ser repetido e gerenciado.

Vamos ver agora algumas características de qualidade:

 Interoperabilidade: capacidade do produto de software de interagir com um


ou mais sistemas especificados. Habilidade de dois ou mais sistemas
(computadores, meios de comunicação, redes, software e outros
componentes de TI) de interagir e de intercambiar dados de acordo com um
método definido, de forma a obter os resultados esperados.

 Conformidade: a capacidade do produto de software de estar de acordo com


16712855225

normas, convenções ou regulamentações previstas em leis e prescrições


similares relacionadas à funcionalidade. Pode-se dizer que é o atendimento
às especificações do produto ou processo, avaliada por meio de medições,
testes ou auditorias.

 Tolerância a Falhas: capacidade de um produto de software de manter um


nível de desempenho especificado em casos de defeitos no software ou de
violação de sua interface especificada. Pode-se dizer que é a habilidade de
satisfazer requisitos apesar de suas falhas.

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


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

 Usabilidade: capacidade do produto de software de ser compreendido,


aprendido, operado e atraente ao usuário, quando usado sob condições
especificadas. O software precisa ser fácil de aprender e de usar, permitir
maior produtividade do usuário, flexibilidade de utilização, flexibilidade de
aplicação e proporcionar satisfação de uso.

GARANTIA E CONTROLE DE QUALIDADE

Galera, vamos falar um pouco sobre a diferença entre Garantia de Qualidade e


Controle de Qualidade. A Garantia de Qualidade está focada no processo de
desenvolvimento de software e prevenção de defeitos, já o Controle de Qualidade
está focado no produto entregue ao usuário e a detecção e correção de defeitos.
Essa é a diferença fundamental que vocês têm de decorar!

A Garantia de Qualidade é orientada ao processo e busca analisá-lo para descobrir


problemas e oportunidades de melhoria com foco na monitoração do processo –
geralmente ocorre no início das fases do ciclo de vida de software. Já o Controle de
Qualidade é orientado ao produto e busca detectar problemas nesse produto
entregue ao usuário – geralmente ocorre no final das fases do ciclo de vida.

Professor, o que seria um exemplo de Garantia de Qualidade? Seria uma mudança


na metodologia de desenvolvimento de software ou definição de métricas e
medição. Professor, o que seria um exemplo de Controle de Qualidade? Seria verificar
se os requisitos que foram definidos são os requisitos corretos ou realizar inspeções
e testes de software.

O Controle de Qualidade engloba um conjunto de ações de engenharia de software


que ajudam a garantir que cada produto resultante atinja suas metas de qualidade,
permitindo a uma equipe de software ajustar o processo quando qualquer um
16712855225

desses produtos resultantes deixe de atender às metas estabelecidas para a


qualidade. Entenderam melhor?

A Garantia de Qualidade estabelece a infraestrutura que suporta métodos sólidos


de engenharia de software, gerenciamento racional de projeto e ações de controle
de qualidade. Ela consiste em um conjunto de funções de auditoria e de relatórios
que possibilita uma avaliação da efetividade e da completude das ações de controle
de qualidade. Em outras palavras, ela vem antes e após o controle de qualidade.

Tenho outra pergunta para vocês: Controle de Qualidade estaria mais associado à
Verificação ou Validação? Pressman nos responde essa pergunta: "In this chapter, I

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


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

use the term ‘quality assurance’ to include Verification and Validation and the
processes of checking that quality procedures have been properly applied". Logo, o
Controle de Qualidade engloba ambos: Verificação e Validação.

Vamos ver um quadro com as principais diferenças entre Garantia de Qualidade e


Controle de Qualidade:

GARANTIA DA QUALIDADE CONTROLE DE QUALIDADE

Garantia da qualidade garante que o processo As atividades de controle da qualidade focam


é definido e apropriado. na descoberta de defeitos em i específicos.

Metodologia e padrões de desenvolvimento Um exemplo de controle da qualidade poderia


são exemplos de garantia da qualidade. ser: "Os requisitos definidos são os requisitos
certos?"
Garantia da qualidade é orientada a processo. Controle da qualidade é orientado a produto.

Garantia da qualidade é orientada a Controle da qualidade é orientado a detecção.


prevenção.

Foco em monitoração e melhoria de processo. Inspeções e garantia de que o produto de


trabalho atenda aos requisitos especificados.

As atividades são focadas no início das fases As atividades são focadas no final das fases
no ciclo de vida de desenvolvimento de no ciclo de vida de desenvolvimento de
software. 16712855225
software.
Garantia da qualidade garante que você está Controle da qualidade garante que os
fazendo certo as coisas e da maneira correta. resultados do seu trabalho são os esperados
conforme requisitos.

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


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(FCC – 2014 – TRT/1 – Analista de Sistemas) A qualidade de software constitui-se


em um fator de grande importância no seu desenvolvimento. Dentre as
propriedades utilizadas para determinar a qualidade de software,

a) mede-se, exclusivamente, a qualidade da documentação produzida para o


software.

b) verifica-se a satisfação de requisitos estabelecidos, incluindo o desempenho.

c) não se abrange questões relativas à interface do software.

d) não há preocupação com a facilidade de manutenção do software.

e) não se inclui a confiabilidade esperada do software.

Comentários:

(a) Apenas a documentação? Não, inclusive a documentação – mas mede-se


diversos aspectos do software;

(b) Perfeito, verifica se os requisitos estabelecidos forem satisfeitos pelo software


desenvolvimento – tanto funcionais como não-funcionais (ex: desempenho);
16712855225

(c) Abrange, sim! Na verdade, abrange-se tanto requisitos funcionais como não-
funcionais (ex: interface);

(d) Há preocupação, sim! Facilidade de manutenção de software é um requisito não-


funcional que deve ter preocupação com a qualidade;

(e) Inclui, sim! Esse também é um requisito não-funcional que deve ser incluído na
preocupação com a qualidade de um software.

Gabarito: B

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


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(FCC – – AFR/SP – Analista de Sistemas Na prática de garantia de


qualidade de software, contrapondo com o controle de qualidade de software,
se aplica a atividade:

a) Definir planos de desenvolvimento de teste.


b) Executar teste de software.
c) Desenvolver casos de teste.
d) Definir métricas e medição.
e) Definir estratégias de testes.

Comentários:

A Garantia de Qualidade é orientada ao processo e busca analisá-lo para descobrir


problemas e oportunidades de melhoria com foco na monitoração do processo –
geralmente ocorre no início das fases do ciclo de vida de software. Já o Controle de
Qualidade é orientado ao produto e busca detectar problemas nesse produto
entregue ao usuário – geralmente ocorre no final das fases do ciclo de vida.

Para responder essa pergunta, devemos buscar o item que se foca no processo de
desenvolvimento de software e, não, no produto. Observem que todos os itens
falam de testes, que se referem em geral ao Controle de Qualidade. Já o quarto
item se refere à definição de métricas e medição, que tem função de melhorar o
processo de software.

Gabarito: D

(CESPE – 2010 – SERPRO - Analista de Sistemas 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
16712855225

gerência sênior da organização com a visibilidade apropriada sobre o processo


de desenvolvimento.

Comentários:

Fácil, não?! A questão apenas inverteu os conceitos de garantia e controle de


qualidade.

Gabarito: E

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


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(CESPE – 2010 – SERPRO - Analista de Sistemas Um processo de gerenciamento


da qualidade do projeto tipicamente visa garantir e controlar a qualidade. No
controle da qualidade, são executadas atividades planejadas e sistemáticas
visando garantir que o projeto empregará os processos necessários 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 estão
de acordo com os padrões relevantes de qualidade e procura identificar meios
para eliminar as causas de resultados que sejam insatisfatórios.

Comentários:

A questão inverteu os conceitos de garantia e controle de qualidade.

Gabarito: E

ACERTEI ERREI

16712855225

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


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

VERIFICAÇÃO & VALIDAÇÃO

Em seu livro, Pressman diz:

Durante e depois do processo de implementação, o programa em


desenvolvimento deve ser verificado para certificar-se de que ele atende a sua
especificação e entrega a funcionalidade esperada pelas pessoas que pagam
pelo software. Verificação e Validação (V&V) é a denominação dada a esses
processos de verificação e análise. Atividades de verificação e validação
ocorrem em cada estágio do processo de software. V&V começa com revisões
de requisitos e continua ao longo das revisões de projeto e das inspeções de
código até o teste de produto.

Percebam que Validação e Verificação são coisas diferentes! E qual a diferença? Ora,
Boehm descreveu de uma maneira simples e genial, por meio de duas perguntas:

 Verificação: Estamos construindo o produto corretamente?


 Validação: Estamos construindo o produto correto?

16712855225

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


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

A Verificação ocorre em ambiente de desenvolvimento e envolve a certificação de


que o software construído esteja de acordo com as especificações de requisitos
(funcionais e não-funcionais)! Já a Validação ocorre em ambiente de produção e se
certifica de que o software construído está de acordo com as expectativas do cliente.
Produto está de acordo com as especificações? Ele satisfaz os anseios dos usuários?

Eu peço a vocês! Não, na verdade eu imploro que vocês memorizem a diferença


entre esses dois conceitos! É muito simples, mas eu já me cansei das incontáveis
vezes que eu vi questões de prova tentando confundir os candidatos e obtendo
êxito. Como você decorou, professor? Muito simples! Verificação ocorre em relação
à Especificação de Requisitos!

Há dois tipos de Verificação: Estática e Dinâmica! A Estática (também chamada


Inspeção de Software) trata da análise de documento de requisitos, análise de
diagramas de projetos, análise de código-fonte, etc. Ela ocorre sem a necessidade
16712855225

de executar o software e pode ocorrer de forma automatizada, antes mesmo da


implementação do sistema.

Já a Verificação Dinâmica (também chamada de Teste) envolve executar o software/


protótipo, i.e., a partir dos dados de entrada, examina-se o comportamento por
meios das saídas, de modo que se verifique se o desempenho obtido está de acordo
com o esperado. Grosso modo, a Estática trata da documentação e a Dinâmica trata
da execução em si.

Calma, nem tudo são flores! Para fazer uma boa Verificação Estática, é necessário
que as especificações dos artefatos sejam precisas e confiáveis – ademais, não é fácil

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


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

nem barato! Quanto à Verificação Dinâmica, nós falaremos mais adiante sobre cada
tipo de teste que pode ser feito. Galera, Verificação Estática e Dinâmica são
complementares e, não, opostas!

Cabe salientar também que a V&V não garante que o software seja completamente
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. Ele tem que ser suficientemente confiável para a utilização
pretendida.

Espera aí... e quem diz o que é um software suficientemente confiável? Bem, isso
depende da criticidade do sistema, das expectativas do utilizador, do ambiente de
marketing, etc! Imaginemos um sistema de catálogo de filmes de uma locadora e
um sistema de controle de tráfego aéreo: qual desses necessita de um grau de
confiança mais alto? ¬¬

Imaginemos, agora, um sistema de caixa de padaria ou o sistema de estoque de um


mercadinho, o utilizador pode ter baixas expectativas sobre o sistema e, assim, ter
um grau de confiança menor sem prejudicar seu funcionamento. Nesses casos, é
comum aceitar falhas de sistema quando os benefícios do uso ultrapassam as
desvantagens.

Por fim, algumas vezes um software precisa ser lançado no mercado rapidamente
como resposta à concorrência ou a um ambiente de marketing favorável. Por
exemplo: quando uma empresa tem poucos concorrentes, ela pode liberar um
programa antes que ele tenha sido inteiramente testado e depurado porque
querem ser os primeiros do mercado.

Galera, muita gente acha que as Inspeções de Software não têm importância. Ora,
16712855225

têm sim! Elas ocorrem, inclusive, em todos os estágios do processo de


desenvolvimento de software – qualquer representação legível do software pode
ser inspecionada. Evidentemente, não é possível usar técnicas estáticas para verificar
requisitos não-funcionais (desempenho, etc).

Outra confusão bastante frequente ocorre entre Teste e Depuração! No entanto,


essa é diferença é bastante simples: dentre outras, testes estabelecem a existência
de defeitos e geralmente são feitos por uma equipe de testes. Já a depuração
localiza e conserta esses defeitos e geralmente é feita por uma equipe de
desenvolvimento. Ficou fácil de entender agora, né?!

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


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(Instituto Cidades – 2012 - CEMIG - Agente de Gestão Administrativa - Analista


de Sistemas - A) O teste é uma atividade de verificação e validação do software
e consiste na análise dinâmica do mesmo, isto é, na execução do produto de
software com o objetivo de verificar a presença de defeitos no produto e
aumentar a confiança de que o mesmo está correto.

Comentários:

Perfeito, é exatamente isso!

Gabarito: C

(CESPE - – Anatel – Analista Administrativo – Arquitetura de Soluções)


Considere as informações abaixo em relação ao desenvolvimento de sistemas:

I. executar um software com o objetivo de revelar falhas, mas que não prova a
exatidão do software.
II. correta construção do produto.
III. Construção do produto certo.

Correspondem corretamente a I, II e III, respectivamente,


16712855225

a) Validação, verificação e teste.


b) Verificação, teste e validação.
c) Teste, verificação e validação.
d) Validação, teste e verificação.
e) Teste, validação e verificação.

Comentários:

Questão estranha, na medida em que Teste é um dos tipos de Verificação: (I) Teste
– por conta da execução do software; (II) Verificação – é semelhante a “Estamos

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


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

construindo o produto corretamente?”; (III) Validação – é semelhante a “Estamos


construindo o produto correto?”.

Gabarito: C

(CESPE - 2010 – TJ/ES – Analista Judiciário – Analista de Sistemas) Verificação e


validação são atividades da análise de software, necessárias para se identificar o
que o software precisa executar, seguida de uma avaliação do usuário quanto às
atividades definidas.

Comentários:

É isso mesmo! Verificação é em relação à especificação de requisitos e a Validação


é em relação aos usuários.

Gabarito: C

(CESPE - – TRT 5ª – alista Judiciário – Analista de Sistemas) A diferença


entre verificação e validação reside no fato de que a primeira se refere ao
conjunto de atividades que garante que o software realiza corretamente uma
função específica, enquanto a segunda refere-se a um conjunto diferente de
atividades que garante que o software que foi construído é rastreável às
exigências do cliente.

Comentários:

Perfeita definição – é isso mesmo!

16712855225

Gabarito: C

(ESAF - – MPOG – Analista de Planejamento – Analista de Sistemas - B)


Demonstrar ao desenvolvedor e ao cliente que o software atende aos requisitos
é uma meta de validação do software.

Comentários:

Conforme vimos em aula, isso é a meta da validação do software.

Gabarito: C

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 14 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(CESPE - 2008 – IPEA – Analista de Sistemas) A verificação assegura que o


produto, como fornecido, irá atender o seu uso pretendido, ou seja, que se está
construindo o produto certo. E a validação confirma que os produtos de trabalho
refletem de forma apropriada os requisitos que foram especificados, ou seja, que
se está construindo o produto corretamente.

Comentários:

Nã-não! É o contrário!

Gabarito: E

(FCC - 2009 – AFR/SP - Analista de Sistemas) O processo de confirmação que


um software vai ao encontro das especificações de software se trata de um
conceito-chave de qualidade denominado:

a) Confiabilidade.
b) Validação.
c) Verificação.
d) Precisão.
e) Acurácia.

Comentários:

16712855225

Conforme vimos em aula, trata-se claramente da Verificação.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 15 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Gabarito: C

(CESPE - 2010 – TRE/ES - Analista de Sistemas) O teste de validação tem por


finalidade encontrar defeitos e inconsistências no programa com relação a sua
especificação.

Comentários:

Na verdade, quem faz isso é o Teste de Verificação.

Gabarito: E

(FCC - 2013 – ALERN - Analista de Sistemas) O teste de software é destinado a


mostrar que um programa faz o que é proposto a fazer e a descobrir seus
defeitos antes do uso. O processo de teste tem dois objetivos distintos:

1. Demonstrar ao desenvolvedor e ao cliente que o software atende a seus


requisitos.
2. Descobrir situações em que o software se comporta de maneira incorreta,
indesejável ou de forma diferente das especificações.

Desse modo, é correto afirmar que:

a) não é objetivo final dos processos de verificação validar os requisitos de


especificação que não reflitam os desejos ou necessidades dos clientes.
b) os testes podem mostrar a presença de erros e sua ausência.
c) o objetivo de todo teste é verificar se ele atende apenas aos requisitos
funcionais. 16712855225

d) verificação e validação não são a mesma coisa em relação a testes de sistema.


e) os testes podem demonstrar que um determinado software está livre de
defeitos.

Comentários:

(a) Errado, o objetivo final de verificar se um software está de acordo com sua
especificação é verificar também se está de acordo com os requisitos do cliente, i.e.,
a verificação é um meio para a validação.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 16 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(b) Errado, testes não demonstram ausência de erros, apenas sua presença – isso
tem que ficar concretado na cabeça de vocês!

(c) Errado, nós vimos em aula que são os requisitos funcionais e não-funcionais –
essa veio fácil!

(d) Correto, a verificação ocorre em ambiente de desenvolvimento em relação às


especificações de software; a validação ocorre em ambiente de produção em
relação às expectativas do cliente.

(e) Errado, nós já vimos que isso deve ficar memorizado – testes jamais demonstram
ausência de defeitos, apenas presença de defeitos.

Gabarito: D

ACERTEI ERREI

16712855225

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 17 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

ERRO, FALTA, FALHA 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
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
ERRO esperado, i.e., 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.
FALHA Pode ter sido causada por diversos erros e alguns erros podem nunca causar
uma falha. Afetam diretamente o usuário final.

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


ERRO apresentadas com as esperadas – nem todas as falhas causarão erros no
16712855225

programa.
Incapacidade de o sistema executar suas funções requeridas dentro das
FALHA exigências especificadas – não existe falha se o programa não tem defeito.

DE ACORDO COM PRESSMAN


Problema de qualidade descoberto após o software ser lançado aos usuários
DEFEITO finais ou após outra atividade de um processo de software.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 18 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Problema de qualidade descoberto antes de o software ser lançado aos


ERRO usuários finais ou após outra atividade de um processo de software.

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


FALHA exigências 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
DEFEITO sistema. Por exemplo, 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
ERRO inesperado pelos seus usuários.

Um evento que ocorre em algum momento, quando o sistema não fornece um


FALHA serviço 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

16712855225

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!

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 19 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Vamos ver outro exemplo? Imaginem que um cabo de rede de uma impressora se
desconectou (aqui está o defeito!), provocando um problema 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 desejados pelo usuário (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.

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, tentem não cai – eu já rodei várias vezes nisso!
16712855225

De acordo com a IEEE 610, Testes de Software revelam falhas e a Depuração de


Software descobre defeitos – percebam que são diferentes. Já de acordo com
Pressman, Testes de Software revelam defeitos e a Depuração de Software descobre
erros. Infelizmente, vocês terão que conviver com esses conceitos muitas vezes
contraditórios em sua vida de concurso! =[

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 20 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

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

DE ACORDO COM IEEE 610


Ato inconsistente cometido por um indivíduo ao tentar entender uma
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
ERRO esperado, i.e., 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.
FALHA Pode ter sido causada por diversos erros e alguns erros podem nunca causar
uma falha. Afetam diretamente o usuário final.
16712855225

Conforme vimos em aula, a questão troca os conceitos de Erro e Falha.

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 21 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

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, tentem não cair –
eu já rodei várias vezes nisso!

De acordo com a IEEE 610, Testes de Software revelam falhas e a Depuração de


Software descobre defeitos – percebam que são diferentes. Já de acordo com
Pressman, Testes de Software revelam defeitos e a Depuração de Software descobre
erros. Infelizmente, vocês terão que conviver com esses conceitos muitas vezes
contraditórios em sua vida de concurso! =[

Conforme vimos em aula, está de acordo com a IEEE 610.

Gabarito: C

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

Comentários:

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
16712855225

cabo estiver desconectado, nenhuma falha se


manifestará! Percebam, então, que Defeitos
causam Erros que podem causar Falhas.

Conforme vimos em aula, Defeitos provocam Erros, que podem gerar Falhas, que
são comportamentos inesperados em um software.

Gabarito: E

(IADES - 2012 - EBSERH- Analista de Informática) Segundo Pressman (2011), a


definição de defeito de software é um problema de qualidade encontrado,

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 22 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(a) Somente após a liberação de uso do software para os usuários finais.


(b) Antes de o software ser liberado aos usuários finais.
(c) Na fase de revisão.
(d) Na fase de levantamento de requisitos.
(e) Na fase de prototipação.

Comentários:

DE ACORDO COM PRESSMAN


Problema de qualidade descoberto após o software ser lançado aos usuários
DEFEITO finais ou após outra atividade de um processo de software.

Problema de qualidade descoberto antes de o software ser lançado aos


ERRO usuários finais ou após outra atividade de um processo de software.

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


FALHA exigências especificadas – não existe falha se o programa não tem defeito.

Conforme vimos em aula, é somente após a liberação de uso do software.

Gabarito: A

ACERTEI ERREI

16712855225

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


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

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.

A primeira meta conduz ao Teste de Validação, no qual você espera que o sistema
seja executado corretamente em um dado conjunto de casos de teste que refletem
o uso esperado do sistema. A segunda meta conduz ao teste de defeitos, no qual
são projetados casos de teste para expor defeitos. Os casos de teste podem ser
obscuros e não precisam refletir como o sistema é usado normalmente.

Os testes de software não podem demonstrar que um software é livre de defeitos


ou que ele se comportará conforme especificado em todas as circunstâncias
existentes. É 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”. Captaram?

A meta é convencer os desenvolvedores e clientes do sistema de que o software é


bom o suficiente para o uso operacional. O teste é um processo voltado a atingir a
confiabilidade do software. Para o Teste de Validação, um teste bem-sucedido é
aquele em que o sistema funciona corretamente. Para o Teste de Defeitos, um teste
bem-sucedido é o que expõe um defeito que causa o funcionamento incorreto.

O que é um Teste de Software? Como é possível de prever, há diversas definições


16712855225

diferentes de diversos autores. Myers, por exemplo, diz que é o processo de


executar um determinado software com a intenção de encontrar defeitos. Já 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 International Software Testing Qualifications Board (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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 24 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Pessoal, um bom teste é aquele que tem alta probabilidade de encontrar um erro;
é aquele que não é redundante; e é aquele não deve ser nem muito simples e nem
muito complexo. Ao longo de diversos anos, Engenharia de Software evoluiu
bastante, 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, mas mesmo se
nenhum defeito for encontrado não quer dizer que ele não os tenha.

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

AGRUPEM 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, de forma a ter alta
probabilidade de encontrar defeitos.

PARADOXO DO PESTICIDA!

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 25 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

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.

TESTES DEPENDEM DO CONTEXTO!

Os testes devem ser elaborados de acordo com o contexto de utilização do software. Ex:
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? I.e., há outros fatores!

16712855225

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 26 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

PROCESSO DE TESTE

O Processo de Software pode ser visto como na espiral ilustrada na imagem abaixo!
Inicialmente, a Engenharia de Sistemas define o papel do software e passa à análise
dos requisitos de software, em que são estabelecidos o domínio da informação,
função, comportamento, desempenho, restrições e critérios de validação para o
software. Entendido?

Descolando-se para o interior da espiral, chega-se ao projeto e finalmente à


codificação. Para desenvolver softwares de computador, percorre-se a espiral para
o interior (sentido anti-horário) ao longo de linhas que indicam a diminuição do
nível de abstração em cada volta. Uma Estratégia de Teste de software também
pode ser vista no conceito da espiral, mas esse não é nosso foco no momento.

O processo de teste de software pode produzir diversos artefatos, dois muito


importantes: plano de testes e casos de teste. O primeiro apresenta o planejamento
16712855225

para execução do teste, incluindo a abrangência, abordagem, recursos e


cronograma das atividades de teste, etc. Identifica os itens e as funcionalidades a
serem testados, as tarefas realizadas e os riscos associados com a atividade de teste.

Ele, em geral, possui os seguintes campos: identificador; referências; introdução;


itens de teste (funções); riscos de software; características a serem (ou não) testadas;
abordagem (estratégia)1; critérios de aceite e falha; critérios de suspenção e
requisitos de retomada; entregáveis de teste; tarefas de teste; necessidades de
ambiente; responsabilidades; entre vários outros.

1
Inclui os responsáveis; tipos de teste; ferramentas; restrições; indicadores; entre outros.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 27 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

De acordo com o RUP, ele busca definir e comunicar a intenção do esforço de teste
em determinada programação. Como em outros documentos de planejamento, o
principal objetivo é ganhar a aceitação e aprovação dos envolvidos no esforço de
teste. Para isso, o documento deve evitar informações que não serão
compreendidas ou que serão consideradas irrelevantes pelos envolvidos.

Ele também determina o framework no qual os papéis de teste funcionarão em


determinada programação. Ele direciona, orienta e restringe o esforço de teste,
priorizando os produtos liberados úteis e necessários. Em culturas ou domínios nos
quais os planos de teste não são reconhecidos como artefatos formais, é importante
considerar os diversos aspectos representados pelo plano de teste.

Já o Caso de Teste é um artefato que contém um conjunto de condições/entradas


usadas para testar um software, podendo ser elaborado para identificar defeitos na
estrutura interna do software por meio de situações que exercitem adequadamente
todas as estruturas utilizadas na a codificação; ou ainda, garantir que os requisitos
do software que foi construído sejam plenamente atendidos.

Ele, em geral, possui os seguintes campos: descrição, pré-condições, entradas,


ações; pontos de observação, pontos de controle, resultados esperados e pós-
condições. De acordo com o RUP, ele busca identificar e comunicar formalmente as
condições específicas detalhadas que serão validadas para permitir a avaliação de
determinados aspectos dos itens de teste-alvo. Entenderam direitinho?

Casos de Teste podem ser motivados por vários fatores, mas normalmente incluirão
um subconjunto dos requisitos e dos riscos envolvidos no projeto. Galera, agora
voltando um pouco! O RUP apresenta diversos artefatos desenvolvidos como
produtos das atividades de teste. Esses dois são os mais importantes, mas existem
16712855225

outros caras importantes. Captaram?

Por fim, uma observação importante que eventualmente é cobrada em provas (eu
detesto questões assim!). É importante salientar que o Plano de Teste é um artefato
de responsabilidade do Gerente de Testes e o Caso de Testes é um artefato de
responsabilidade do Analista de Testes. Por fim, há também o Testador, que é um
cara que desenha os scripts e faz o trabalho mais operacional.

O ciclo de vida de testes é composto de cinco fases, como apresenta a imagem


abaixo! Na etapa de Planejamento, elaboram-se o Projeto de Testes e o Plano de
Testes, e também é responsável por fazer a análise de riscos dos projetos de testes.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 28 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Na etapa de Preparação, organiza-se o ambiente de testes, com infraestrutura


adequada e pessoal capacitado, registrando e controlando as versões do produto.

Na etapa de Especificação, elaboram-se e revisam-se os Casos de Teste e os


Roteiros (Scripts) de Teste. Na etapa de Execução, preparam-se os dados de testes,
executam-nos, solucionam-se ocorrências, acompanha-se a execução dos casos de
teste e elabora-se um relatório final. Por fim, na Entrega, avalia-se e arquiva-se a
documentação, gerando um relatório com as conformidades e não-conformidades.

16712855225

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 29 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

ESTRATÉGIA DE TESTES

Teste é um conjunto de atividades que podem ser planejadas com antecedência e


executadas sistematicamente. Por essa razão, deverá ser definido para o processo
de software um modelo (template) para o teste – um conjunto de etapas no qual
pode-se colocar técnicas específicas de projeto de caso de teste e métodos de teste.
Muitas estratégias de teste de software já foram propostas na literatura.

Todas elas fornecem um modelo para o teste e todas têm as seguintes


características genéricas:

 Para executar um teste eficaz, proceder a revisões técnicas eficazes. Fazendo


isso, muitos erros serão eliminados antes do começo do teste.

 O teste começa no nível de componente e progride em direção à integração do


sistema computacional como um todo.

 Diferentes técnicas de teste são apropriadas para diferentes abordagens de


engenharia de software e em diferentes pontos no tempo.

 O teste é feito pelo desenvolvedor do software e (para grandes projetos) por um


grupo independente de teste.

 O teste e a depuração são atividades diferentes, mas a depuração deve ser


associada com alguma estratégia de teste.

Uma estratégia de teste de software deve acomodar testes de baixo nível,


necessários para verificar se um pequeno segmento de código fonte foi
implementado corretamente, bem como testes de alto nível, que validam as funções
16712855225

principais do sistema de acordo com os requisitos do cliente. Uma estratégia deverá


fornecer diretrizes para o profissional e uma série de metas para o gerente.

Devido ao fato de os passos da estratégia de teste ocorrerem no instante em que


as pressões pelo prazo começam a aumentar, deve ser possível medir o progresso
no desenvolvimento e os problemas devem ser revelados o mais cedo possível. A
Estratégia de Teste (Estágios/ Níveis de Teste) são agrupados de acordo com o
momento em que eles são executados ou pelo nível de especificidade do teste.

Há muitas estratégias que podem ser utilizadas para testar um software. Em um dos
extremos, pode-se esperar até que o sistema esteja totalmente construído e, então,

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 30 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

executar os testes no sistema completo esperando encontrar os erros. Essa


abordagem, embora atraente, simplesmente não funciona; resultará em um
software defeituoso que desagrada todos os que investiram nele.

No outro extremo, você pode executar testes diariamente, sempre que uma parte
do sistema seja construída. Essa abordagem, embora menos atraente, pode ser
muito eficaz. Uma estratégia que é preferida pela maioria das equipes de software
está entre os dois extremos. Ela assume uma visão incremental do teste, conforme
é apresentado na espiral.

A imagem acima mostra que a espiral se inicia em sentido horário pelo Teste de
Unidade, que é responsável por analisar o código em si; em seguida realiza o Teste
de Integração, que é responsável por analisar o projeto; depois o Teste de
Validação/Aceitação, que é responsável por analisar os requisitos do usuário; e, por
16712855225

fim, o Teste de Sistema, é responsável por analisar o sistema como um todo.

Testes de Software podem se dividir em Baixo Nível (1º Nível) e Alto Nível (2º Nível)!
Nos Testes de Baixo Nível, o profissional deve ter um profundo conhecimento da
estrutura interna do software. Por esse motivo, é natural nas empresas que as fases
desse nível de teste sejam transferidas para o próprio desenvolvedor, pois ele possui
toda a carga de conhecimento que é necessária para realizar essas atividades.

Galera, pode-se notar que o primeiro nível é composto pelos Testes Unitários e
Testes de Integração. Já nos Testes de Alto Nível, não é necessário conhecimento
da estrutura interna do software. Os testes são guiados pelas especificações de

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 31 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

negócio e pela lista de requisitos do software. O segundo nível é composto pelos


Testes de Validação e Testes de Sistema.

O Teste de Unidade começa no centro da espiral e se concentra em cada unidade


(Ex: componente, classe, objeto, entre outros) do software conforme implementado
no código-fonte. O teste prossegue movendo-se em direção ao exterior da espiral,
passando pelo Teste de Integração, em que o foco está no projeto e construção da
arquitetura de software.

Continuando na mesma direção da espiral, encontramos o Teste de Validação, em


que requisitos estabelecidos como parte dos requisitos de modelagem são
validados em relação ao software criado. Finalmente, chegamos ao Teste de
Sistema, no qual o software e outros elementos são testados como um todo e, não,
em partes separadas.

Para testar um software de computador, percorre-se a espiral em direção ao seu


exterior, no sentido horário, ao longo de linhas que indicam o escopo do teste a
cada volta. Considerando o processo de um ponto de vista procedimental, o teste
dentro do contexto de engenharia de software é na realidade uma série de quatro
etapas que são implementadas sequencialmente.

Inicialmente, os testes focalizam cada componente individualmente, garantindo que


ele funcione adequadamente como uma unidade, daí o nome Teste de Unidade. O
Teste de Unidade usa intensamente técnicas de teste com caminhos específicos na
estrutura de controle de um componente para garantir a cobertura completa e a
máxima detecção de erros.

Em seguida, o componente deve ser montado ou integrado para formar o pacote


completo de software. O Teste de Integração cuida de problemas associados com
16712855225

aspectos de verificação e construção do programa, ainda em um ambiente de


desenvolvimento (e, não, produção). Técnicas de projeto de casos de teste que
focalizam em entradas e saídas são mais predominantes durante a integração.

Apesar disso, técnicas que usam caminhos específicos de programa podem ser
utilizadas para segurança dos principais caminhos de controle. Depois que o
software foi integrado (construído), é executada uma série de testes de ordem
superior (como mostra a imagem abaixo da pirâmide). Os critérios de validação
devem ser avaliados.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 32 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

O Teste de Validação proporciona a garantia final de que o software satisfaz a todos


os requisitos informativos, funcionais, comportamentais e de desempenho. A última
etapa de teste extrapola os limites de engenharia de software, entrando em um
contexto mais amplo de engenharia de sistemas de computadores, combinando
elementos do sistema (por exemplo, hardware, pessoas, base de dados).

O Teste de Sistema verifica se todos os elementos se combinam corretamente e se


a função ou desempenho global do sistema foi conseguida com êxito. Pessoal, essa
é a visão do Pressman! Já Sommerville possui uma visão diferente sobre Estágios de
Teste, dividindo-o em Teste de Componente, Teste de Sistema e Teste de Aceitação.
Vamos ver isso em detalhes...

De acordo com essa visão, os componentes do sistema são testados, depois é


testado o sistema integrado e, finalmente, o sistema é testado com os dados do
16712855225

cliente. De maneira ideal, os defeitos de componentes são descobertos no início do


ocesso e os problemas de interface, quando o sistema for integrado. No entanto,
à medida que os defeitos são descobertos, o programa deve ser depurado.

Isso pode requerer que outros estágios no processo de teste sejam repetidos. Os
erros nos componentes de programa podem aparecer durante o teste de sistema.
O processo é, portanto, iterativo, com as informações sendo realimentadas dos
estágios posteriores para as partes iniciais do processo. O Processo de Teste (de
Sommerville) é apresentado na imagem a seguir.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 33 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Chegou a hora de ver cada estágio com mais detalhes. Vamos falar sobre o Teste
de Unidade, Teste de Integração, Teste de Sistema e Teste de Validação:

TESTE DE UNIDADE (COMPONENTE OU MÓDULO)

Esse teste focaliza o esforço de verificação na menor unidade de projeto do software


– o componente ou módulo de software. Usando como guia a descrição de projeto
no nível de componente, caminhos de controle importantes são testados para
descobrir erros dentro dos limites do módulo. A complexidade relativa dos testes e
os erros que revelam são limitados pelo escopo restrito estabelecido para esse teste.

Ele enfoca a lógica interna de processamento e as estruturas de dados dentro dos


limites de um componente. Esse tipo de teste pode ser conduzido em paralelo para
16712855225

diversos componentes. A interface de um módulo é testada para assegurar que as


informações fluam corretamente para dentro a para fora da unidade de programa
que está sendo testada.

A estrutura de dado local é examinada para garantir que os dados armazenados


temporariamente mantenham sua integridade durante todos os passos na execução
de um algoritmo. Todos os caminhos independentes da estrutura de controle são
usados para assegurar que todas as instruções em um módulo tenham sido
executadas pelo menos uma vez.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 34 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

As condições-limite são testadas para garantir que o módulo opere adequadamente


nas fronteiras estabelecidas para limitar ou restringir o processamento. Finalmente,
são testados todos os caminhos de manipulação de erro. Para Sommerville, é o
processo de teste de componentes individuais do sistema. Este é um processo de
teste de defeitos e, portanto, sua meta é expor defeitos nesses componentes.

Existem diferentes tipos de componentes que podem ser testados nesse estágio:
Funções ou métodos individuais de um objeto; classes de objeto com vários
atributos e métodos; componentes compostos que constituem diferentes objetos
ou funções. Esses componentes compostos têm uma interface definida usada para
acessar sua funcionalidade.

As funções ou métodos individuais são os tipos mais simples de componentes e


seus testes são um conjunto de chamadas dessas rotinas com diferentes parâmetros
de entrada. Eles verificam o funcionamento de um pedaço do sistema ou software
isoladamente ou que possam ser testados separadamente, e 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. Geralmente são feitos pelos próprios
desenvolvedores e, não, por especialistas em testes. Por meio de Testes de Unidade,
é possível encontrar problemas mais cedo; facilita mudanças; simplifica integrações;
auxilia a documentação; melhora o projeto do software; entre outros.

TESTE DE INTEGRAÇÃO

Um novato no mundo do software pode levantar uma questão aparentemente


gítima quando todos os módulos tiverem passado pelo teste de unidade: Se todos
funcionam individualmente, porque você duvida que eles funcionem quando
16712855225

estiverem juntos? O problema, naturalmente, é “colocá-los todos juntos” – aqui nós


estamos falando de interfaces.

Dados podem ser perdidos através de uma interface; um componente pode ter um
efeito inesperado ou adverso sobre outro, subfunções, quando combinadas, podem
não produzir a função principal desejada; imprecisão aceitável individualmente
pode ser amplificada em níveis não aceitáveis; estruturas de dados globais podem
apresentar problemas. Infelizmente, essa lista não tem fim!

Teste de Integração é uma técnica sistemática para construir a arquitetura de


software ao mesmo tempo que conduz testes para descobrir erros associados com

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 35 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

as interfaces. O objetivo é construir uma estrutura de programa determinada pelo


projeto a partir de componentes testados em unidade. Muitas vezes, há uma
tendência de tentar integração não incremental.

Ou seja, construir o programa usando uma abordagem big bang. Todos os


componentes são combinados com antecedência. O programa inteiro é testado
como um todo. E, usualmente, o resultado é o caos, porque muitos erros podem
ser encontrados de uma só vez e a sua correção fica difícil, visto que há muito
espaço para procurar e isolar a causa do erro.

Uma vez corrigidos esses erros, novos erros aparecem e o processo parece não ter
fim. A integração incremental é o oposto da abordagem big bang. O programa é
construído e testado em pequenos incrementos, em que os erros são mais fáceis de
isolar e corrigir; as interfaces têm maior probabilidade de serem testadas
completamente; e uma abordagem sistemática de teste pode ser aplicada.

Para Sommerville, Testes de Integração e Testes de Release – são componentes d


Teste de Sistema (em sistemas complexos). O Teste de Integração trata do esforço
de verificação em uma combinação de componentes para checar se eles funcionam
corretamente juntos, conforme as especificações. Busca encontrar defeitos nas
interfaces e nas interações entre componentes ou sistemas integrados.

TESTE DE VALIDAÇÃO (ACEITAÇÃO)

O Teste de Validação começa quando termina o teste de integração, quando os


componentes individuais já foram exercitados, o software está completamente
montado como um pacote e os erros de interface já foram descobertos e corrigidos.
O teste focaliza simplesmente ações visíveis ao usuário e saídas do sistema
reconhecíveis pelo usuário. 16712855225

A validação pode ser definida de várias maneiras, mas uma definição simples
(embora rigorosa) é que a validação tem sucesso quando o software funciona de
uma maneira que pode ser razoavelmente esperada pelo cliente. Nesse ponto, um
desenvolvedor de software veterano pode dizer: Quem ou o que é o árbitro para
decidir o que são expectativas razoáveis?

Se foi desenvolvida uma Especificação de Requisitos de Software, ela descreve todos


os atributos do software visíveis ao usuário e contém uma seção denominada
Critérios de Validação, que forma a base para uma abordagem de Teste de

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 36 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Validação. Para tal, existem os Testes Alfa e Testes Beta, que serão vistos agora com
mais detalhes.

É praticamente impossível para um desenvolvedor de software prever como o


cliente usará um programa. As instruções de uso podem ser mal interpretadas,
combinações estranhas de dados podem ser usadas regularmente; resultados que
pareciam claros para o testador podem ser confusos para um usuário no campo de
utilização. Entendido?

Quando é construído um software personalizado para um cliente, são feitos Testes


de Aceitação para permitir ao cliente validar todos os requisitos e decidir se ele é
bom o suficiente para ser implantado. Conduzido pelo usuário final e não por
engenheiros de software, um Teste de Aceitação pode variar de um informal test
driver até uma série de testes planejados e sistematicamente executados.

Na verdade, um teste de aceitação pode ser executado por um período de semanas


ou meses, descobrindo assim erros cumulativos que poderiam degradar o sistema
ao longo do tempo. Se um software é desenvolvido como um produto para ser
usado por muitos clientes, é impraticável executar testes formais de aceitação para
cada cliente.

Muitos construtores de software usam um processo chamado de Teste Alfa e Teste


Beta para descobrir erros que somente o usuário final parece ser capaz de
encontrar. O Teste Alfa é conduzido na instalação do desenvolvedor por um grupo
representativo de usuários finais. O software é usado em um cenário natural com o
desenvolvedor “espiando em cima dos ombros” do usuário.

Dessa forma, ele registra os erros e os problemas de uso. Os Testes Alfa são
conduzidos em um ambiente controlado. Já o Teste Beta é conduzido nas
16712855225

instalações de um ou mais usuários finais. Diferentemente do Teste Alfa, o


desenvolvedor geralmente não está presente. Portanto, o Teste Beta é uma
aplicação “ao vivo” do software em um ambiente que não pode ser controlado.

O cliente registra todos os problemas (reais ou imaginários) encontrados durante o


Teste Beta e relata esses problemas para o desenvolvedor em intervalos regulares.
Como resultado dos problemas relatados durante o Teste Beta, os engenheiros de
software fazem modificações e então preparam a liberação do software para todos
os clientes.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 37 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Uma variação do Teste Beta, chamada de Teste de Aceitação do Cliente, às vezes


executada quando é fornecido software personalizado a um cliente sob contrato. O
cliente executa uma série de testes específicos na tentativa de descobrir erros antes
de aceitar o software do desenvolvedor. Em alguns casos (por exemplo, um grande
sistema corporativo ou governamental) o Teste de Aceitação pode ser muito formal.

TESTE DE SISTEMA

Galera, um software é apenas um elemento de um grande sistema de computador.


No final, o software é incorporado com outros elementos do sistema (por exemplo,
hardware, pessoas, informações), e é executada uma série de testes de integração
de sistema e validação. Esses testes estão fora do escopo do processo de software
e não são executados somente por engenheiros de software.

No entanto, as etapas executadas durante o projeto de software e o teste podem


aumentar muito a probabilidade de uma integração de software bem-sucedida em
um sistema maior. Um problema clássico de teste de sistema é a “procura do
culpado”. Isso ocorre quando é descoberto um erro e os desenvolvedores de
diversos elementos do sistema começam a acusar um ao outro pelo problema.

Em vez de adotar essa postura sem sentido, você deve se antecipar aos problemas
potenciais de interface e (1) criar caminhos de manipulação de erro que testem todas
as informações vindas de outros elementos do sistema; (2) executar uma série de
testes que simulem dados incorretos ou outros erros potenciais na interface de
software.

(3) Deve registrar os resultados dos testes para usar como evidência se ocorrer a
caça ao culpado; e (4) participar do planejamento e projeto de testes do sistema
para assegurar que o software seja testado adequadamente. O Teste de Sistema é
16712855225

na realidade uma série de diferentes testes cuja finalidade primária é exercitar


totalmente o sistema.

Embora cada um dos testes tenha uma finalidade diferente, todos funcionam no
sentido de verificar se os elementos do sistema foram integrados adequadamente
e executam as funções a eles alocadas. Como eu disse anteriormente, Sommerville
divide Testes de Sistema em duas fas (para sistemas complexos): Testes de
Integração e Testes de Releases. É bom saber essa diferença!

O Teste de Sistema envolve a integração de dois ou mais componentes que


implementam funções ou características do sistema e depois o teste desse sistema

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 38 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

integrado. Em um processo de desenvolvimento iterativo, o teste de sistema


concentra-se no teste de um incremento que será entregue ao cliente; em um
processo em cascata, o teste de sistema concentra-se no teste de todo o sistema.

Segundo Sommerville, no Teste de Integração: a equipe de testes deve acessar o


código-fonte do sistema. Quando um problema é descoberto, a equipe de
integração tenta encontrar a origem do problema e identificar os componentes que
devem ser depurados. Os Testes de Integração geralmente estão relacionados à
descoberta de defeitos no sistema.

O Teste de Integração verifica se esses componentes funcionam em conjunto, se


são chamados corretamente e se transferem dados corretos no tempo correto por
meio de suas interfaces. A integração envolve a identificação de componentes que
realizam alguma funcionalidade, e a integração desses componentes ao adicionar
códigos que fazem com que eles trabalhem em conjunto.

Segundo Sommerville, no Teste de Release: uma versão do sistema, que poderia ser
liberada aos usuários, é testada. Aqui, a equipe de testes concentra-se em validar
se o sistema atende aos requisitos e em assegurar que o sistema é confiável. O Teste
de Releases é normalmente um Teste Caixa-Preta no qual a equipe de testes
concentra-se em demonstrar se o sistema funciona adequadamente ou não.

Os problemas são reportados à equipe de desenvolvimento, cujo trabalho é depurar


o programa. Os clientes são envolvidos no Teste de Releases que, algumas vezes, é
chamado de Teste de Aceitação. Se o release for bom o suficiente, o cliente poderá
aceitá-lo para seu uso. Como vocês devem ter percebido, eu não gosto muito do
Sommerville para esse assunto! Ele é extremamente confuso e desorganizado.

16712855225

PRESSMAN (7ª Edição)

Teste de Unidade
Teste de Integração
Teste de Validação
Teste de Sistema

O Pressman divide em quatro estágios bem definidos. Você testa as unidades


separadamente; depois você as integra e testa se funcionam em conjunto; depois
você testa com os usuários em um ambiente controlado e em um ambiente real; e,

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 39 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

por fim, você testa se o software funciona harmonicamente no sistema em que será
inserido, i.e., com outros hardwares, pessoas, informações, etc.

SOMMERVILLE (8ª EDIÇÃO) – SISTEMAS DE GRANDE PORTE

Teste de Componente/Unidade
Teste de Integração
Teste de Sistema
Teste de Release
Teste de Aceitação

SOMMERVILLE (8ª EDIÇÃO) – SISTEMAS DE PEQUENO PORTE

Teste de Componente/Unidade
Teste de Sistema
Teste de Aceitação

Sommerville divide em três estágios pouco definidos. Você testa os componentes


separadamente; depois – caso seja um sistema complexo – você os integra e testa
se funcionam em conjunto; depois você testa uma versão com os usuários. Essas
duas últimas fases são chamadas de Teste de Sistema, no entanto temos alguns
problemas na organização dessas ideias.

Ele afirma que são três estágios: Componente > Sistema > Aceitação. Em sistemas
de grande porte, o Teste de Sistema é composto de um Teste de Integração e um
Teste de Release. No entanto, depois ele afirma que Teste de Release é também um
Teste de Aceitação. E, por fim, ele afirma que um Teste de Aceitação é um Teste
16712855225

Alfa. Acompanharam essa maluquice? Sommervile!

Em outras palavras, é possível até concluir que Teste de Integração é sinônimo de


Teste de Sistema. Ele afirma: “Fundamentalmente, você pode pensar no teste de
integração como o teste de sistemas incompletos compostos de clusters e
agrupamentos de componentes de sistema”. Vocês perceberam como é confuso?
Pois é, acho que ele mesmo percebeu e resolveu mudar na última edição (2011).

Eu tenho que falar das duas, porque as duas vocês podem eventualmente resolver
uma questão antiga. Bem, na última edição, ele afirma que – tipicamente – um
sistema de software comercial deve passar por três estágios de testes: Teste de

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 40 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Desenvolvimento, Teste de Release e Teste de Usuário (percebam que mudou


bastante em relação à versão anterior). Vamos ver cada uma delas em detalhes.

SOMMERVILLE (9ª EDIÇÃO)

Teste de Unidade
Teste de
Teste de Componente
Desenvolvimento
Teste de Sistema
Teste de Release
Teste de Usuário

Os Testes de Desenvolvimento são aqueles em que a equipe de desenvolvimento


testa o sistema durante o desenvolvimento para descobrir bugs e defeitos.
Projetistas e programadores serão os prováveis envolvidos no processo de testes.
Os Testes de Release são aqueles em que uma equipe de testes separada testa uma
versão completa do sistema antes de ele ser liberado para os usuários.

O objeto do Teste de Release é verificar se o sistema está de acordo com os


requisitos das partes interessadas do sistema. Por fim, os Testes de Usuário são
aqueles em que usuários ou potenciais usuários de um sistema testam o sistema em
seu próprio ambiente. O Teste de Aceitação é um tipo de Teste de Usuário em que
o cliente formalmente testa o sistema para decidir se deve ser aceito ou não.

Percebam que o discurso mudou nessa nova versão. Ele afirma, por exemplo, que
existem três níveis de granularidade para Testes de Desenvolvimento: Testes de
Unidade, Testes de Componente e Testes de Sistema. O primeiro testa unidades
individuais, com foco na funcionalidade de objetos ou métodos. O segundo testa
componentes (que são um conjunto de unidades individuais).
16712855225

Esse teste deve se concentrar em testar a interface de componentes. r fim, o


último testa a interação de componentes que trabalham como um todo. Professor,
qual a diferença entre um Teste de Sistema e um Teste de Release? A diferença é que
Teste de Sistema busca defeitos no sistema como um todo e é realizado pela equipe
de desenvolvimento.

O Teste de Release é feito por uma equipe não envolvida no desenvolvimento e


não busca defeitos. Na verdade, ele checa se o sistema está de acordo com seus
requisitos e está suficientemente bom para uso externo (semelhante a um Teste de

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 41 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Validação). Deve-se convencer o cliente de que o sistema entrega o que foi


especificado funcionalmente e não-funcionalmente.

Vamos fazer um resumão? Você testa as unidades (Teste de Unidade); junta as


unidades em componentes compostos e testa suas interfaces (Teste de
Componente); junta os componentes e testa suas interações (Teste de Sistema);
manda para outra equipe verificar se está de acordo com a especificação (Teste de
Release); por fim, os clientes testam em Testes Alfa, Beta e de Aceitação.

Professor, espera um pouco! Cadê o Teste de Integração? Pois é, ele sumiu nessas
últimas edições. Eu sei que você já deve estar com raiva, mas infelizmente é assim.
Cada um cria um conceito, depois muda de opinião, some com o conceito e fica
por isso mesmo – isso gera diversas inconsistências em prova. Vocês querem saber
a minha opinião como professor e profissional?

Para mim, isso é só teoria, porque – na prática – a ordem mais clara é: Teste de
Unidade, Teste de Integração, Teste de Sistema e Teste de Aceitação. Qual dos
nossos dois autores favoritos segue essa ordem? Nenhum, mas o mais próximo é o
Pressman! Alguns autores menos consagrados (Tripathy e Naik, Craig e Jaskiel)
também veem os estágios dessa maneira:

 Teste de Unidade: seu objetivo é isolar cada unidade individual do programa


(um método, uma função, um loop, uma declaração, etc) e verificar se elas estão
funcionando de modo correto (independentemente das outras unidades); em
16712855225

geral, trata-se de um teste caixa-branca e se concentra em testes funcionais;

 Teste de Integração: seu objetivo é combinar módulos e testá-los como um


grupo para verificar se funcionam de modo correto (logo, é dependente de
outros módulos); em geral, trata-se tanto de um teste caixa-branca como de um
teste caixa-preta e se concentra em testes funcionais.

 Teste de Sistema: seu objetivo é testar o sistema como um todo para verificar se
o sistema funciona de modo correto ou não (i.e., de acordo com seus requisitos
ou não); em geral, trata-se de um teste caixa-preta e se concentra tanto em
testes funcionais como em testes não-funcionais.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 42 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

 Teste de Aceitação: seu objetivo é que o usuário/cliente teste o sistema para


verificar se ele está de acordo com sua expectativa e se ele aceita o sistema ou
não, primeiro com um Teste Alfa e depois com um Teste Beta; em geral, trata-
se de um teste caixa-preta e se concentra apenas em testes funcionais.

16712855225

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 43 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

TÉCNICAS DE TESTES

Galera, 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 imagem abaixo as
apresenta como um plano cartesiano de três dimensões. Acabamos de ver a
segunda perspectiva, vamos ver as outras. As Técnicas de Teste de Software buscam
demonstrar como testar.

Por fim, os Tipos de Testes buscam demonstrar o que testar. Essas três perspectivas
são apresentadas na imagem abaixo e serão detalhadas para melhor entendimento.

16712855225

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 44 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

As Técnicas se dividem em: Testes Caixa-Branca, Testes Caixa-Preta e Testes Caixa-


Cinza. A primeira se foca nas estruturas internas dos procedimentos do sistema. A
segunda se foca nas entradas e saídas especificadas nos requisitos funcionais. Por
fim, 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, Programático,


Orientada à Lógica ou Caixa- -Vidro) analisa caminhos lógicos possíveis de serem
executados, portanto é necessário ter conhecimento sobre o funcionamento interno
dos componentes. Ela 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 do software. 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 abaixo:

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


procedimento e a utiliza para definir um conjunto 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, Procedimental,


Funcional, Orientada a Dado ou à Entrada/Saída) se baseia em pré-condições e pós-
16712855225

condições, geralmente sendo utilizada nas etapas posteriores da disciplina de testes.


Ela busca funções incorretas ou inexistentes, erros de comportamento ou
desempenho, erros de inicialização e interface, etc.

Deriva casos de teste a partir da especificação de requisitos, ignorando detalhes de


implementação e se focando nas saídas geradas em resposta a entradas escolhidas
e condições especificadas. Baseia-se em pré e pós-condições; geralmente utilizada
no fim do processo de testes e busca erros de comportamento, desempenho,
inicialização e término, interface, etc; além de funções incorretas ou inexistentes.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 45 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Essa técnica 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 componente de software. 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 redundância e aumentar a cobertura de testes do sistema.

 Análise de Valor Limite: permite 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 espalhados uniformemente pelo domínio do teste para detectar falhas.

Por fim, o Teste Caixa-Cinza realiza uma mistura entre os Testes Caixa-Branca e
Caixa-Preta. Portanto o desenvolvedor dos testes não tem acesso ao código-fonte,
no entanto possui acesso a estruturas de dados e conhecimento dos algoritmos
implementados, assim como pode manipular arquivos de entrada/saída, entre
outros. Alguns autores definem o Teste de Integração como Teste Caixa-Cinza.

16712855225

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 46 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

TIPOS DE TESTES

Galera, agora veremos vários tipos de testes. Preciso que vocês entendam o
seguinte: tentei achar o máximo de questões sobre cada um, porém existem
centenas de tipos de testes. Portanto, se um tipo de teste específico possui poucos
exercícios, é porque ele cai pouco em prova. É bom vocês analisarem isso para dosar
sua quantidade de estudos em cada assunto. Vamos lá? ;)

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, volume, etc. Em outras palavras, verifica qual limite de dados processados
até a falha do sistema.

Ele pode avaliar a resposta do sistema a uma pesada carga de dados ou uma grande
quantidade usuários simultâneos para avaliar o nível de escalabilidade até o momento
em que o tempo de resposta começa a se degradar. Em geral, esses testes ocorrem
durante os Testes de 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. Ele deve ser
projetado para assegurar que o sistema pode operar na carga necessária, envolvendo,
geralmente, o planejamento de uma série de testes em que a carga é constantemente
16712855225

aumentada até que o desempenho se torne inaceitável.

Define-se um perfil operacional, que é um conjunto de testes que refletem uma


combinação real de trabalho a que o sistema será submetido. Esses testes geralmente
ocorrem paralelamente ao teste de carga, avaliando a capacidade de resposta do
sistema em determinadas configurações.

TESTE DE USABILIDADE

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 47 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

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

TESTE DE CENÁRIOS

O Teste de Cenários utiliza cenários, i.e., estórias hipotéticas para ajudar o testador a
resolver um problema complexo ou testar o sistema. Geralmente são diferentes de
Casos de Teste porque esses últimos são passos singulares enquanto cenários cobrem
um grande número de passos.

TESTE DE REGRESSÃO

Consistem na aplicação de testes em versões mais recentes do software para garantir


que não surgiram novos defeitos em componentes já analisados. Se ao juntar o novo
componente com os componentes restantes do sistema surgirem novos defeitos em
componentes inalterados, então considera-se que o sistema regrediu.

TESTE BACK-TO-BACK / TESTE DE COMPARAÇÃO

Comum em sistemas críticos, realizam-se testes em versões diferentes do software e


os resultados são comparados – não só o conteúdo, mas também o tempo de resposta,
i.e., testes back-to-back são simplesmente testes de comparação. Recebe-se a mesma
16712855225

entrada e compara suas saídas.

Galera, muita gente confunde Teste de Regressão com Teste Back-to-Back. O primeiro
testa se uma alteração no software não inseriu bugs em partes já previamente estadas.
O segundo roda o mesmo teste em duas versões do sistema e compara os resultados
obtidos.

TESTE ALFA E TESTES BETA

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 48 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Testes Alfa são executados quando o desenvolvimento está próximo a sua conclusão.
Este tipo de teste é geralmente realizado por usuários internos e não pelos
programadores ou testadores, porém ocorrem no ambiente do desenvolvedor.
Entenderam? Feitos pelo usuário em um ambiente controlado.

Testes Beta são executados quando o desenvolvimento e testes estão praticamente


concluídos, e o maior número possível de defeitos/problemas precisam ser
encontrados antes da release final. Entenderam? Feitos pelo usuário em seu ambiente
real de trabalho2.

TESTES DE RECUPERAÇÃO

Esses testes validam a capacidade e qualidade da recuperação do software após


crashes, falhas de hardware ou outros problemas catastróficos. Em outras palavras,
eles forçam o software a falhar de várias formas e verifica se a recuperação foi
adequada, podendo ocorrer manual ou automaticamente.

TESTES DE COMPATIBILIDADE

Testes de Compatibilidade validam a capacidade do software de ser executado em um


ambiente particular de hardware, software, sistema operacional, rede, etc. Ele pode ser
automático ou manual e permite descobrir mudanças, realizar as alterações
necessárias, adequar sistemas aos seus ambientes reais, etc.
16712855225

TESTES ESTÁTICOS E DINÂMICOS

Esse é muito simples de entender! Em testes estáticos, o código é examinado à procura


de defeitos, geralmente nas primeiras etapas do projeto; já em testes dinâmicos, o
código é executado à procura de defeitos, geralmente para verificação.

2
Observação: Testes Alfa, Testes Beta e Testes de Aceitação são conhecidos como Testes de Usuário.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 49 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

TESTES DE VULNERABILIDADE

Trata-se de um teste que procura por vulnerabilidades em um sistema e documenta em


relatórios. Em geral, é feita por meio de diversas tentativas de penetração para explorar
fraquezas na arquitetura do sistema ou ambiente computacional.

TESTES DE SEGURANÇA

Algumas vezes chamado de Testes de Ameaça, trata-se de um teste que verifica se os


mecanismos de proteção incorporados a um sistema vão, de fato, protegê-lo de invasão
indevida. Geralmente ocorrem durante os Testes de Integração e Testes de Sistema.

16712855225

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 50 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(CESPE - 2015 – TCU - Analista de Sistemas Os casos de testes são especificações


acerca das entradas para o teste e da saída esperada e englobam, também, uma
declaração do que está sendo testado. Devido ao tamanho do espaço de
possibilidades de teste, a geração automática exaustiva de casos de testes que
exploram todas as entradas e saídas para qualquer configuração de teste é
impossível ou computacionalmente intratável.

Comentários:

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.

Conforme vimos em aula, é inviável testar todo o espaço amostral de testes


possíveis, exceto para casos triviais – mesmo por meio de ferramentas
automatizadas.

Gabarito: C
16712855225

(CESPE - 2010 – SAD/PE – Analista de Sistemas) A respeito do plano de teste, um


registro do processo de planejamento de testes de software, assinale a opção
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 execução de um caso de teste


de software.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 51 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

c) A automação de um teste de integração é mais facilmente empreendida que


a de um teste de módulo.

d) A produção de scripts de teste deve preceder a eventual construção de casos


de teste.

e) Ao se inspecionar o conteúdo de um plano de testes, devem-se encontrar,


entre outras, as seguintes descrições: escopo de testes, abordagens de teste,
recursos para realização dos testes e cronograma das atividades de teste a serem
realizadas.

Comentários:

O ciclo de vida de testes é composto de cinco fases, como apresenta a imagem abaixo!
Na etapa de Planejamento, elaboram-se o Projeto de Testes e o Plano de Testes, e
também é responsável por fazer a análise de riscos dos projetos de testes. Na etapa
de Preparação, organiza-se o ambiente de testes, com infraestrutura adequada e
pessoal capacitado, registrando e controlando as versões do produto.

(a) Conforme vimos em aula, o processo de Planejamento de Testes gera o Plano


de Testes, ele não é descrito por ele.

O processo de teste de software pode produzir diversos artefatos, dois muito


importantes: plano de testes e casos de teste. O primeiro apresenta o planejamento
para execução do teste, incluindo a abrangência, abordagem, recursos e cronograma
das atividades de teste, etc. Identifica os itens e as funcionalidades a serem testados,
as tarefas realizadas e os riscos associados com a atividade de teste.

(b) Conforme vimos em aula, ele é um planejamento para execução do teste de


16712855225

software.

(c) Basta raciocinar! Quem é mais difícil de automatizar? Ora, um Teste de Integração
é muito mais complexo que um Teste de Módulo. Logo, a questão não faz sentido!

Na etapa de Especificação, elaboram-se e revisam-se os Casos de Teste e os Roteiros


(Scripts) de Teste. Na etapa de Execução, preparam-se os dados de testes, executam-
nos, solucionam-se ocorrências, acompanha-se a execução dos casos de teste e
elabora-se um relatório final. Por fim, na Entrega, avalia-se e arquiva-se a
documentação, gerando um relatório final de testes e um de não-conformidade.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 52 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(d) Conforme vimos em aula, a elaboração de Scripts de Testes ocorre na etapa de


Especificação; a execução ocorre posteriormente na etapa de Execução.

O processo de teste de software pode produzir diversos artefatos, dois muito


importantes: plano de testes e casos de teste. O primeiro apresenta o planejamento
para execução do teste, incluindo a abrangência, abordagem, recursos e cronograma
das atividades de teste, etc. Identifica os itens e as funcionalidades a serem testados,
as tarefas realizadas e os riscos associados com a atividade de teste.

(e) Conforme vimos em aula, o escopo é representado pelas características a serem


testadas ou não; e os recursos são representados pelas necessidades de equipe e
de treinamento.

Gabarito: E

(CESPE - 1 – MEC – Analista de Sistemas) Ao ser estabelecido, um plano de


testes necessita de diversos insumos, sendo um deles a estratégia de testes.

Comentários:

Ele, em geral, possui os seguintes campos: identificador; referências; introdução; itens


de teste (funções); riscos de software; características a serem (ou não) testadas;
abordagem (estratégia); critérios de aceite e falha; critérios de suspenção e requisitos
de retomada; entregáveis de teste; tarefas de teste; necessidades de ambiente;
responsabilidades; entre vários outros.

Conforme vimos em aula, ele necessita da abordagem ou da estratégia de testes.

16712855225

Gabarito: C

(CESPE - 2011 – MEC – Analista de Sistemas) Na definição do documento


referente ao plano de testes, devem ser incluídos os tipos e a metodologia dos
testes. No entanto, critérios de aceitação e processos associados fogem ao
escopo desse documento e devem ser inseridos na análise dos riscos.

Comentários:

Ele, em geral, possui os seguintes campos: identificador; referências; introdução; itens


de teste (funções); riscos de software; características a serem (ou não) testadas;
abordagem (estratégia); critérios de aceite e falha; critérios de suspenção e requisitos

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 53 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

de retomada; entregáveis de teste; tarefas de teste; necessidades de ambiente;


responsabilidades; entre vários outros.

Conforme vimos em aula, todos estão abrangidos pelo Plano de Testes.

Gabarito: E

(CESPE - 2011 – TJ/ES – Analista de Sistemas) Conforme o RUP, o plano de teste,


artefato da disciplina de teste de responsabilidade do testador, reúne as
informações necessárias para planejar e controlar o esforço de teste referente a
uma iteração específica ou ao projeto e, entre outros itens, deve conter o tipo
de teste a ser realizado, sua estratégia e as ferramentas necessárias para sua
execução.

Comentários:

Por fim, uma observação importante que eventualmente é cobrada em provas (eu
detesto questões assim!). É importante salientar que o Plano de Teste é um artefato
de responsabilidade do Gerente de Testes e o Caso de Testes é um artefato de
responsabilidade do Analista de Testes. Por fim, há também o Testador, que é um
cara que desenha os scripts e faz o trabalho mais operacional.

Conforme vimos em aula, Plano de Testes é um artefato de responsabilidade do


Gerente de Testes.

Gabarito: E

(CESPE - 2011 – TJ/ES – Analista de Sistemas) No plano de teste, um documento


de nível gerencial, definem-se como o teste vai ser realizado, quem vai executar
16712855225

os testes, o prazo estimado e o nível de qualidade esperado.

Comentários:

O processo de teste de software pode produzir diversos artefatos, dois muito


importantes: plano de testes e casos de teste. O primeiro apresenta o planejamento
para execução do teste, incluindo a abrangência, abordagem, recursos e cronograma
das atividades de teste, etc. Identifica os itens e as funcionalidades a serem testados,
as tarefas realizadas e os riscos associados com a atividade de teste.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 54 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Conforme vimos em aula, ele tanto é gerencial que é responsabilidade do Gerente


de Testes. Como o teste vai ser realizado (abordagem); quem vai executar os testes
(responsabilidades); prazo estimado (cronograma); e nível de qualidade (critérios de
aceite e falha).

Gabarito: C

(CESPE - 2007 – TSE – Analista de Sistemas – D) Entre os artefatos produzidos


por um processo de teste, têm-se os casos de teste. Um caso de teste é uma
situação real de uso, pois não pode ser sintetizado a partir de parâmetros
predefinidos.

Comentários:

Ele, em geral, possui os seguintes campos: descrição, pré-condições, entradas, ações;


pontos de observação, pontos de controle, resultados esperados e pós-condições. De
acordo com o RUP, ele busca identificar e comunicar formalmente as condições
específicas detalhadas que serão validadas para permitir a avaliação de determinados
aspectos dos itens de teste-alvo. Entenderam direitinho?

Conforme vimos em aula, ele não é uma situação real! Além disso, pode sim ser
sintetizado a partir de parâmetros predefinidos. Há, inclusive, uma sessão para
descrição das pré-condições, resultados esperados e pós-condições.

Gabarito: E

(CESPE - – MPE/RR – Analista de Sistemas) No Processo Unificado, um


modelo de teste é tipicamente composto por casos de teste, os quais podem
especificar como testar cenários específicos de casos de uso. Os casos de teste
16712855225

tipicamente especificam entradas, resultados esperados e outras condições


relevantes para as verificações dos cenários.

Comentários:

Ele, em geral, possui os seguintes campos: descrição, pré-condições, entradas, ações;


pontos de observação, pontos de controle, resultados esperados e pós-condições. De
acordo com o RUP, ele busca identificar e comunicar formalmente as condições
específicas detalhadas que serão validadas para permitir a avaliação de determinados
aspectos dos itens de teste-alvo. Entenderam direitinho?

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 55 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Conforme vimos em aula, está perfeito! Ele, em geral, possui os seguintes campos:
resumo, pré-condições, entradas, ações, resultados esperados e pós-condições.

Gabarito: C

(CESPE - 2011 – MEC – Analista de Sistemas) Na etapa de execução, os roteiros


dos testes são insumos necessários, que descrevem a relação dos casos de testes
e a previsão de execução.

Comentários:

Na etapa de Especificação, elaboram-se e revisam-se os Casos de Teste e os Roteiros


(Scripts) de Teste. Na etapa de Execução, preparam-se os dados de testes, executam-
nos, solucionam-se ocorrências, acompanha-se a execução dos casos de teste e
elabora-se um relatório final. Por fim, na Entrega, avalia-se e arquiva-se a
documentação, gerando um relatório final de testes e um de não-conformidade.

Conforme vimos em aula, os roteiros ou scripts de teste são produtos da etapa de


especificação e insumos da etapa de execução!

Gabarito: C

10. (CESPE - 2011 – MEC – Analista de Sistemas) A elaboração de scripts para teste
é um dos insumos necessários na etapa de planejamento.

Comentários:

Na etapa de Especificação, elaboram-se e revisam-se os Casos de Teste e os Roteiros


(Scripts) de Teste. Na etapa de Execução, preparam-se os dados de testes, executam-
16712855225

nos, solucionam-se ocorrências, acompanha-se a execução dos casos de teste e


elabora-se um relatório final. Por fim, na Entrega, avalia-se e arquiva-se a
documentação, gerando um relatório final de testes e um de não-conformidade.

Conforme vimos em aula, ele é um dos insumos necessários na etapa de Execução.

Gabarito: E

11. (CESPE - 2011 – MEC – Analista de Sistemas) Em um projeto de teste, após ser
concluída a etapa de execução, inicia-se a etapa de entrega, cujos produtos
incluem o relatório de não conformidades.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 56 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Comentários:

Conforme vimos em aula, está perfeito!

Gabarito: C

12. (CESPE - 2011 – MEC – Analista de Sistemas) A etapa de planejamento pode ser
verificada por testes estáticos e ter a documentação do sistema revisada.
16712855225

Comentários:

Essa questão não faz sentido, na medida em que Testes Estáticos verificam o
código-fonte de um programa, logo não podem ser utilizados na etapa de
Planejamento.

Gabarito: E

13. (CESPE - 2011 – MEC – Analista de Sistemas) Na etapa de especificação, ocorrem


a elaboração e a revisão dos casos de testes.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 57 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Comentários:

Na etapa de Especificação, elaboram-se e revisam-se os Casos de Teste e os Roteiros


(Scripts) de Teste. Na etapa de Execução, preparam-se os dados de testes, executam-
nos, solucionam-se ocorrências, acompanha-se a execução dos casos de teste e
elabora-se um relatório final. Por fim, na Entrega, avalia-se e arquiva-se a
documentação, gerando um relatório final de testes e um de não-conformidade.

Conforme vimos em aula, está perfeito!

Gabarito: C

14. (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:

Por fim, uma observação importante que eventualmente é cobrada em provas (eu
detesto questões assim!). É importante salientar que o Plano de Teste é um artefato
de responsabilidade do Gerente de Testes e o Caso de Testes é um artefato de
responsabilidade do Analista de Testes. Por fim, há também o Testador, que é um
cara que desenha os scripts e faz o trabalho mais operacional.

Conforme vimos em aula, todas essas atividades fazem parte do rol de


responsabilidades do Testador e, não, do Analista de Testes.
16712855225

Gabarito: E

15. (CESPE - 2011 - MEC - Gerente de Projetos) Para qualquer sistema,


independentemente do seu tamanho, as etapas de teste devem seguir a seguinte
sequência: testes de componente, testes de integração e testes de sistema.

Comentários:

SOMMERVILLE (8ª EDIÇÃO) – SISTEMAS DE GRANDE PORTE

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 58 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Teste de Componente/Unidade
Teste de Integração
Teste de Sistema
Teste de Release
Teste de Aceitação

SOMMERVILLE (8ª EDIÇÃO) – SISTEMAS DE PEQUENO PORTE

Teste de Componente/Unidade
Teste de Sistema
Teste de Aceitação

Conforme vimos em aula, Sommerville afirma que – para sistemas complexos –


Testes de Sistema são compostos por Testes de Integração e Testes de Release. Para
sistemas de pequeno porte, não se divide os Testes de Release. Ela se encaixa mais
na definição dos outros autores. Observem que ela não diz que você é obrigado a
fazer todas essas etapas, apenas diz que – se existirem – devem seguir a ordem
citada.

Gabarito: C

16. (CESPE - – TSE - Analista de Sistemas – C) Os testes são realizados em


várias fases de um desenvolvimento. Testes de unidade são de baixo nível, testes
de sistema são executados após os de integração, testes beta empregam apenas
16712855225

desenvolvedores.

mentários:

Galera, pode-se notar que o primeiro nível é composto pelos Testes Unitários e Testes
de Integração. Já nos Testes de Alto Nível, não é necessário conhecimento da
estrutura interna do software. Os testes são guiados pelas especificações de negócio
e pela lista de requisitos do software. O segundo nível é composto pelos Testes de
Validação e Testes de Sistema.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 59 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Dessa forma, ele registra os erros e os problemas de uso. Os Testes Alfa são
conduzidos em um ambiente controlado. Já o Teste Beta é conduzido nas instalações
de um ou mais usuários finais. Diferentemente do Teste Alfa, o desenvolvedor
geralmente não está presente. Portanto, o Teste Beta é uma aplicação “ao vivo” do
software em um ambiente que não pode ser controlado.

Conforme vimos em aula, Testes de Unidade são de baixo nível e Testes de Sistema
são executados após os Testes de Integração. No entanto, Testes Beta empregam
em sua maioria usuários e, não, desenvolvedores.

Gabarito: E

17. (CESPE - 2010 – MPE/TO - Analista de Sistemas) Entre os diversos níveis possíveis
de testes de software, há os chamados testes de unidade (Unit Tests), que
procuram testar o programa como um todo, dentro de um contexto totalmente
integrado, procurando validar todas as suas potencialidades de forma unificada.

Comentários:

Continuando na mesma direção da espiral, encontramos o Teste de Validação, em


que requisitos estabelecidos como parte dos requisitos de modelagem são validados
em relação ao software criado. Finalmente, chegamos ao Teste de Sistema, no qual
o software e outros elementos são testados como um todo e, não, em partes
separadas.

Conforme vimos em aula, isso é Teste de Sistema e, não, Teste de Unidade.

Gabarito: E
16712855225

18. (CESPE - 2010 – TJ/ES - Analista de Sistemas) No teste de unidade, o software é


forçado a falhar de diversos modos a fim de verificar se os requisitos funcionais
foram adequadamente implementados. As unidades, sejam funções,
procedimentos, métodos ou classes, são testadas duas a duas. Nesse teste,
espera-se identificar erros relacionados a algoritmos incorretos ou mal
implementados, estruturas de dados incorretas ou simples erros de
programação.

Comentários:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 60 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Testes Unitários são feitos um-a-um! Além disso, Teste de Unidade não força o
software até a falha, quem faz isso é o Teste de Recuperação.

Gabarito: E

19. (CESPE - 2013 - MPU - Analista - Desenvolvimento de Sistemas) Para se avaliar


a documentação do projeto do software, deve ser utilizado o teste de unidade.

Comentários:

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. Geralmente são feitos pelos próprios
desenvolvedores e, não, por especialistas em testes. Por meio de Testes de Unidade,
é possível encontrar problemas mais cedo; facilita mudanças; simplifica integrações;
auxilia a documentação; melhora o projeto do software; entre outros.

Conforme vimos em aula, ele auxilia a documentação. No entanto, não se pode


dizer que ele deve ser utilizado. Eu acredito que o mais adequado para avaliar a
documentação do projeto do software seria o teste de integração ou de sistema.

Gabarito: E

(CESPE - 2012 - MPE-PI - Analista Ministerial - Informática - Cargo 6) Os testes


de unidade são feitos por equipes especializadas em testes, de forma a se
garantir que os módulos que compõem o sistema sob construção estejam
funcionando de acordo com as especificações.

Comentários:
16712855225

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. Geralmente são feitos pelos próprios
desenvolvedores e, não, por especialistas em testes. Por meio de Testes de Unidade,
é possível encontrar problemas mais cedo; facilita mudanças; simplifica integrações;
auxilia a documentação; melhora o projeto do software; entre outros.

Conforme vimos em aula, eles são feitos pelos próprios desenvolvedores e, não, por
uma equipe especializada em testes.

Gabarito: E

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 61 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

21. (CESPE - 2011 - BRB - Analista de Tecnologia da Informação) Os testes de


unidade, normalmente feitos pelos próprios desenvolvedores, sem necessidade
de processos muito formais, são tratados dentro do próprio fluxo de
implementação por meio de métodos simplificados.

Comentários:

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. Geralmente são feitos pelos próprios
desenvolvedores e, não, por especialistas em testes. Por meio de Testes de Unidade,
é possível encontrar problemas mais cedo; facilita mudanças; simplifica integrações;
auxilia a documentação; melhora o projeto do software; entre outros.

Conforme vimos em aula, eles são feitos pelos próprios desenvolvedores sem muita
formalidade.

Gabarito: C

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

Para Sommerville, Testes de Integração e Testes de Release – são componentes do


Teste de Sistema (em sistemas complexos). O Teste de Integração trata do esforço de
verificação em uma combinação de componentes para checar se eles funcionam
16712855225

corretamente juntos, conforme as especificações. Busca encontrar defeitos nas


interfaces e nas interações entre componentes ou sistemas integrados.

Conforme vimos em aula, a questão está perfeita!

Gabarito: C

(CESPE - – IPEA - Analista de Sistemas) Os testes de integração verificam


se os componentes do sistema funcionam em conjunto, se os componentes são
chamados corretamente e se os componentes transferem dados corretos via
suas interfaces. Nesses testes, os componentes são testados interligados; podem

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 62 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

ser necessários drivers e stubs para simular componentes ainda não


implementados; e, em sistemas de software orientados a objeto, os stubs podem
ser classes.

Comentários:

Para Sommerville, Testes de Integração e Testes de Release – são componentes do


Teste de Sistema (em sistemas complexos). O Teste de Integração trata do esforço de
verificação em uma combinação de componentes para checar se eles funcionam
corretamente juntos, conforme as especificações. Busca encontrar defeitos nas
interfaces e nas interações entre componentes ou sistemas integrados.

Conforme vimos em aula, a questão está perfeita! Ademais, stubs são fragmentos
de código utilizados para simular um comportamento ou substituir um código –
servem para ajudar o teste!

Gabarito: C

24. (CESPE - – TRE/PR - Analista de Sistemas) Nos testes de integração,


realizados antes dos testes unitários, os componentes são construídos e testados
separadamente.

Comentários:

16712855225

Conforme vimos em aula, Testes de Integração ocorrem após os Testes Unitários.

Gabarito: E

(CESPE - 2011 - Correios - Analista de Correios - Analista de Sistemas -


Desenvolvimento de Sistemas) Em um teste de integração, é possível detectar
possíveis falhas provenientes da integração interna dos componentes de um
sistema. O teste de integração sucede o teste de unidade, no qual os módulos
são testados individualmente, e antecede o teste de sistema, em que o sistema
completo é testado.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 63 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Comentários:

 Teste de Integração: seu objetivo é combinar módulos e testá-los como um grupo


para verificar se funcionam de modo correto (logo, é dependente de outros
módulos); em geral, trata-se tanto de um teste caixa-branca como de um teste
caixa-preta e se concentra em testes funcionais.

Conforme vimos em aula, a questão está perfeita! O Teste de Integração sucede o


Teste de Unidade e antecede o teste de Sistema.

Gabarito: C

(CESPE - 2013 – ANTT - Analista de Sistemas) O teste de aceitação pode utilizar


um processo chamado de teste alfa e beta, sendo conduzido por
desenvolvedores e podendo contar com a participação do usuário. O teste alfa
é realizado em ambiente real e o beta em ambiente controlado.

Comentários:

16712855225

 Teste de Aceitação: seu objetivo é que o usuário/cliente teste o sistema para


verificar se ele está de acordo com sua expectativa e se ele aceita o sistema ou
não, primeiro com um Teste Alfa e depois com um Teste Beta; em geral, trata-se
de um teste caixa-preta e se concentra apenas em testes funcionais.

Conforme vimos em aula, Teste Alfa ocorre em ambiente controlado e Teste Beta
ocorre em ambiente real.

Gabarito: E

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 64 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

27. (CESPE - 2009 – TRE/PR - Analista de Sistemas) O teste de aceitação envolve a


integração de dois ou mais componentes que implementam funções ou
características do sistema. Existem duas fases distintas de teste do sistema: testes
de integração e teste de caixa de vidro.

mentários:

Para Sommerville, Testes de Integração e Testes de Release – são componentes do


Teste de Sistema (em sistemas complexos). O Teste de Integração trata do esforço de
verificação em uma combinação de componentes para checar se eles funcionam
corretamente juntos, conforme as especificações. Busca encontrar defeitos nas
interfaces e nas interações entre componentes ou sistemas integrados.

Conforme vimos em aula, a questão trata de Testes de Integração e, não, Aceitação.


Além disso, as fases do Teste de Sistema são: Testes de Integração e Testes de
Release.

Gabarito: E

(CESPE - – TRE/PR - Analista de Sistemas) Requisitos descrevem um acordo


ou contrato entre duas partes, especificando, entre outros aspectos, o que o
sistema de software deve fazer para ser aprovado em um teste de aceitação.

Comentários:

Quando é construído um software personalizado para um cliente, são feitos Testes


de Aceitação para permitir ao cliente validar todos os requisitos. Conduzido pelo
usuário final e não por engenheiros de software, um Teste de Aceitação pode variar
de um informal test driver até uma série de testes planejados e sistematicamente
16712855225

executados.

Conforme vimos em aula, a questão está perfeita!

Gabarito: C

(CESPE - – TCU - Analista Judiciário - Tecnologia da Informação O teste de


integração consiste em construir gradualmente o sistema, por integração de seus
componentes, e testar o sistema resultante, buscando identificar e analisar
problemas originados a partir das interações entre esses componentes, em um

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 65 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

ambiente de execução com características próximas àquelas a serem utilizadas


no ambiente operacional real.

Comentários:

Em seguida, o componente deve ser montado ou integrado para formar o pacote


completo de software. O Teste de Integração cuida de problemas associados com
aspectos de verificação e construção do programa, ainda em um ambiente de
desenvolvimento (e, não, produção). Técnicas de projeto de casos de teste que
focalizam em entradas e saídas são mais predominantes durante a integração.

Conforme vimos em aula, a questão está errada por falar em ambiente de execução!

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

31. (CESPE - – IPEA - Analista de Sistemas) O teste caixa-preta ou


comportamental, aplicado no início do processo de teste, é embasado nos
requisitos funcionais do software. Identifica, entre outros, erros de iniciação e
término, erros de estrutura de dados, erros de interface e funções incorretas ou
16712855225

omitidas.

Comentários:

No início do processo de teste? Não, geralmente é nas etapas posteriores.

Gabarito: E

(CESPE - – TRE/BA - Analista de Sistemas) A figura a seguir ilustra


esquematicamente a técnica estrutural de teste de software (ou teste caixa-
branca), que avalia o comportamento interno do componente de software,

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 66 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

atuando diretamente sobre o código-fonte do componente para realizar testes


de condição, de fluxo de dados, de ciclos e de caminhos lógicos.

Comentários:

Perfeito, é exatamente isso!

Gabarito: C

(CESPE - – TRE/PR - Analista de Sistemas) Enquanto o teste caixa-preta é


estrutural ou orientado à lógica, o teste caixa-branca é funcional, orientado a
dado ou orientado a entrada e saída.

Comentários:

Testes Caixa-Preta são comportamentais, funcionais, orientados a dado ou à


entrada/saída e os Testes Caixa-Branca são estruturais ou orientados à lógica.

Gabarito: E
16712855225

34. (CESPE - – TRE/PR - Analista de Sistemas) Entre os tipos de testes de caixa


preta, encontram-se o teste baseado em grafos; o particionamento de
equivalência; a análise de valor-limite; e o teste de matriz ortogonal.

Comentários:

Perfeito, é exatamente isso!

Gabarito: C

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 67 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(CESPE - 2010 - ABIN - Oficial Técnico de Inteligência - Área de Desenvolvimento


e Manutenção de Sistemas) Nos testes de caixa branca, o código-fonte do
programa é usado para identificar testes de defeitos potenciais, particularmente
no processo de validação, o qual demonstra se um programa atende a sua
especificação.

Comentários:

Para Validação, utiliza-se o Teste Caixa-Preta! Para Verificação, utiliza-se o Teste


Caixa-Branca.

Gabarito: E

(CESPE - - CEHAP- - Analista de Sistemas - C) Aplicado ao final do


processo de teste, o teste caixa-preta ou comportamental é baseado nos
requisitos funcionais do software.

Comentários:

Perfeito, é exatamente isso!

Gabarito: C

37. (CESPE - - CEHAP- - Analista de Sistemas - C) O teste de caixa-preta


tenta encontrar erros das seguintes categorias: funções incorretas ou omitidas,
erros de interface, erros de estrutura de dados ou de acesso a base de dados
externa, erros de comportamento ou desempenho e erros de iniciação e
término.
16712855225

Comentários:

Perfeito, são todos exemplos de possíveis erros encontrados por Teste Caixa-Preta!
Por que, professor? Porque o Pressman disse:

“Black-box testing attempts to find errors in the following categories: (1) incorrect or
missing functions, (2) interface errors, (3) errors in data structures or external database
access, (4) behavior or performance errors, and (5) initialization and termination
errors”.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 68 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Se vocês me perguntarem como que encontrar erros em estruturas de dados é


função de um teste caixa-preta, eu não sei te responder, mas se o Pressman disse,
então está dito e banca cobra!

Gabarito: C

(CESPE - 2010 - INMETRO - Analista de Sistemas - E) Os testes caixa preta (Black


Box) avaliam as cláusulas de código, a lógica interna do componente codificado,
as configurações e outros elementos técnicos.

Comentários:

Lógica interna do componente codificado? Não, isso é Teste Caixa-Branca!

Gabarito: E

(CESPE - 2010 - INMETRO - Analista de Sistemas - C) Testes de caixa preta são


usualmente fundamentados na análise do código de um programa. Por outro
lado, entre as técnicas de teste não relacionadas a testes de caixa preta, estão
aquelas embasadas na intuição do testador, em especificações comportamentais
e no uso.

Comentários:

Análise de código? Não, é Teste Caixa-Branca!

Gabarito: E

40. (CESPE - 2010 - SERPRO - Analista de Sistemas - C) Com relação ao emprego de


16712855225

diferentes técnicas para a realização de testes de software, é correto afirmar que


haverá maior diminuição da dependência de acesso às especificações
arquiteturais de um sistema se o testador empregar a técnica de caixa-branca
(white-box), em vez das técnicas de caixa-cinza (gray-box) e de caixa-preta
(black-box).

Comentários:

Pelo contrário, haverá maior diminuição da dependência de acesso às


especificações arquiteturais ao se utilizar a técnica caixa-preta, em vez das outras.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 69 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Gabarito: E

41. (CESPE - 2011 - MEC - Analista de Sistemas) O teste denominado caixa-preta é


utilizado para verificar se os requisitos do software são atendidos, sem verificar
o código ou a lógica do componente testado.

Comentários:

Perfeito, é exatamente isso!

Gabarito: C

42. (CESPE - 2011 - MEC - Analista de Sistemas) O teste caixa-branca ou teste de


caixa de vidro é um método de projeto de casos de teste que usa a estrutura de
controle do projeto procedimental para derivar casos de teste. Dessa maneira
garante-se que todos os caminhos independentes de um módulo tenham sido
exercitados pelo menos uma vez, já que erros lógicos e pressupostos incorretos
são inversamente proporcionais à probabilidade de que um caminho de
programa vai ser executado.

Comentários:

Perfeito! Percebam que quanto mais um caminho é percorrido ou executado, menor


a quantidade de erros lógicos e pressupostos incorretos encontrados.

Gabarito: C

43. (CESPE - 2010 - INMETRO - Analista de Sistemas) Os testes caixa branca (White
Box) verificam a funcionalidade e a aderência aos requisitos, em uma ótica
16712855225

externa ou do usuário, sem que se tenha qualquer conhecimento do código e


da lógica interna do componente testado.

Comentários:

Pelo contrário, a questão trata dos Testes Caixa-Preta.

Gabarito: E

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 70 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

44. (CESPE - 2010 – INMETRO - Analista de Sistemas) O teste de caminho básico é


uma técnica que identifica as rotinas normalmente usadas, deixando de lado as
rotinas eventualmente executadas.

Comentários:

O Teste de Caminho Básico é uma técnica que identifica todas as rotinas e caminhos
executados!

Gabarito: E

45. (CESPE - 2010 – TRE/ES - Analista de Sistemas) O teste de partições caracteriza-


se por ser um projeto de caso de teste, em que o conhecimento da estrutura do
programa é utilizado para projetar testes que verificam todas as partes desse
programa.

Comentários:

Não! Teste de Partições de Equivalência é um teste caixa-preta, portanto não utiliza


conhecimento da estrutura do programa!

Gabarito: E

46. (CESPE - 2013 - MPU - Analista - Desenvolvimento de Sistemas) Testes funcionais


são aplicados para identificar não conformidades entre o programa e seus
requisitos.

Comentários:
16712855225

Observe que a questão falou algo bastante genérico. Testes Funcionais podem ser
aplicados para identificar não conformidades entre o programa e seus requisitos? Sim!
Na verdade, qualquer teste é feito em relação aos seus requisitos (de software ou
usuário). Teste de Carga é geralmente em relação a algum requisito não-funcional
do software; Teste de Aceitação é em relação a algum requisito do usuário em seu
contexto; Teste de Usabilidade pode ser em relação aos dois; etc.

Gabarito: C

47. (CESPE - 2012 - ANAC - Analista Administrativo - Área 4) Os testes funcionais


são caracterizados pelo uso do sistema conforme o seu usuário regular o faria.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 71 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Comentários:

O teste caracterizado pelo uso do sistema é o Teste de Usabilidade.

Gabarito: E

48. (CESPE - 2012 - MPE-PI - Analista Ministerial - Informática - Cargo 6) Em teste


funcional, o conjunto de valores de entrada válidos pode ser reduzido por meio
de partição em classes de equivalência, o que torna a quantidade de dados de
entrada finita.

Comentários:

Galera, é mais simples do que parece! Nós já vimos que é inviável (se não,
impossível) testar todas as entradas possíveis de um sistema. A Técnica de Partição
de Equivalência nos permite otimizar o processo de testes por meio da separação
das entradas em classes ou categorias diferentes. Vamos ver um exemplo:

Nós estamos fazendo um sistema de uma escola que recebe a nota final de um
aluno! Vejamos como ficaria:

Se Nota < 5.0  Aluno reprovado


Se Nota >= 5.0 e Nota < 7.0  Aluno em dependência
Se Nota > 7.0  Aluno aprovado

Ora, vejam que beleza! Nós reduzimos as entradas para quatro classes. Professor,
só estou vendo três! Isso é porque nós sempre temos que considerar uma classe de
entradas inválidas (Ex: Nota = $%@& - isso não é uma entrada válida). Dessa forma,
16712855225

eu não preciso testar todos os valores de 0.0 a 5.0, basta escolher um valor (Ex: 3.5),
porque todos os outros valores dessa classe se comportarão da mesma maneira.
Galera, aqui estou sendo bem simplista por conta do exemplo, mas é possível
especificar várias outras entradas, logo teríamos mais partições. As regras para
utilizar essa técnica são:

1) A divisão das partições deve ser bem clara e definida;


2) Não deve ser possível que um elemento se enquadre em partições diferentes;
3) Não é permitida uma partição que não possua membros (vazia);
4) Valores inválidos devem ser considerados.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 72 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Gabarito: C

49. (CESPE - 2011 - MEC - Gerente de Projetos) Quando o objetivo é testar uma
funcionalidade, assegurando-se que, para todo tipo de entrada, a saída
observada corresponda àquela esperada, pode-se alcançar esse objetivo
fazendo-se uso de testes do tipo caixa-branca.

Comentários:

Galera, essa questão é polêmica! Percebam que claramente o mais recomendável é


o Teste Caixa Preta (para testar funcionalidades assegurando a saída esperada para
uma determinada entrada). No entanto, a questão diz que pode- alcançar esse
objetivo por meio de Testes Caixa-branca. Em minha opinião, isso é possível, mas a
banca considerou a questão como errada!

Gabarito: E

(CESPE - 2010 - TRE-BA - Técnico Judiciário - Programação de Sistemas) Teste


funcional é uma técnica para se projetar casos de teste na qual o programa ou
sistema é considerado uma caixa-preta e, para testá-lo, são fornecidas entradas
e avaliadas as saídas geradas.

Comentários:

Perfeito, é exatamente isso!

Gabarito: C

51. (CESPE - 2013 - MPU - Técnico - Tecnologia da Informação e Comunicação) Um


16712855225

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 73 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(CESPE - 2006 – TSE - Analista de Sistemas) Um teste de unidade pode ser


projetado usando-se uma estratégia caixa branca. Nesse caso, há um foco nos
mecanismos internos da unidade sendo testada. A realização de testes caixa
branca pode ser apoiada por métricas de cobertura.

Comentários:

Perfeito, foco em mecanismos internos! Ademais, pode ser apoiada por métricas de
cobertura porque pode medir a quantidade de código testada por um conjunto de
casos de teste.

Gabarito: C

(CESPE - 2013 - MPU - Técnico - Tecnologia da Informação e Comunicação) Para


realizar testes de unidade ou estrutural, pode-se utilizar uma representação
conhecida como grafo de fluxo de controle de um programa. A partir do grafo,
executam-se todos os caminhos do programa, principalmente na presença de
laços.

Comentários:

Vamos por partes: Teste de Unidade é um Nível de Teste e Teste Estrutural (ou
Caixa-Branca) é uma Técnica de Teste - estes conceitos são diferentes e
independentes! A técnica de Grafos de Fluxos de Controle é uma técnica do tipo
Caixa-Preta. Por que? Porque ela trata do relacionamento entre objetos e, não, de
aspectos internos ou estruturais. Além disso, não são executados todos os caminhos
do programa - são exercitados todos os objetos e relacionamentos representados
nos grafos. Acredito que a questão quis fazer o candidato se confundir com a
16712855225

Técnica de Caminho Básico, em que se trata de estruturas internas (Ex: Laços).

Gabarito: E

54. (CESPE - 2010 – TJ/ES - Analista de Sistemas) O teste de integração, a exemplo


do teste caixa-branca, focaliza o esforço de validação na menor unidade de
projeto do software e, com o uso de técnicas de componentização, caminhos de
controle relevantes são testados para descobrir erros dentro dos limites do
componente.

Comentários:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 74 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Quem focaliza o esforço de validação na menor unidade de projeto do software é


o Teste de Unidade e, não, Teste de Integração.

Gabarito: E

(CESPE - 2010 - MPU - Analista de Informática - Desenvolvimento de Sistemas)


O teste de integração geralmente é um processo de teste de caixa-preta no qual
os testes são derivados da especificação do sistema, cujo comportamento pode
ser determinado por meio do estudo de suas entradas e saídas.

Comentários:

Por fim, o Teste Caixa-Cinza realiza uma mistura entre os Testes Caixa-Branca e
Caixa-Preta. Portanto o desenvolvedor dos testes não tem acesso ao código-fonte, no
entanto possui acesso a estruturas de dados e conhecimento dos algoritmos
implementados, assim como pode manipular arquivos de entrada/saída, entre outros.
Alguns autores definem o Teste de Integração como Teste Caixa-Cinza.

Na verdade, Testes de Integração são considerados Testes de Caixa-Cinza, visto que


misturam Testes de Caixa-Branca e Testes de Caixa-Preta.

Gabarito: E

(CESPE - 2013 - INPI - Analista de Planejamento - Desenvolvimento e


Manutenção de Sistemas) De modo geral, o teste de release é um processo de
teste do tipo caixa-branca em que as funcionalidades são verificadas e validadas
mediante a avaliação interna dos módulos.
16712855225

Comentários:

Galera, Caixa-Branca? Não, Caixa Preta!

Gabarito: E

57. (CESPE - 2013 – TRT.17 - Analista de Sistemas) O teste de carga, que verifica o
funcionamento do software, utiliza uma grande quantidade de usuários
simultaneamente.

Comentários:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 75 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Perfeito, o Teste de Carga coloca o software sob uma condição anormal de


quantidade de alguma variável para verificar quanto suporta.

Gabarito: C

(CESPE - – PMV - Analista de Sistemas) O teste de usabilidade em um sítio


da Web tem como objetivo identificar problemas de usabilidade e coletar dados
relacionados ao desempenho e às preferências dos usuários.

Comentários:

Perfeito! Galera, esse desempenho é relacionado à performance dos usuários na


realização de tarefas específicas.

Gabarito: C

(CESPE - – Hemobrás - Analista de Sistemas) Teste de usabilidade consiste


na análise de um website por um grupo de experts em usabilidade.

Comentários:

Testes de Usabilidade não se restringem a websites e são realizados, em geral, pelos


usuários finais.

Gabarito: E

(CESPE - – Hemobrás - Analista de Sistemas) As técnicas de avaliação de


usabilidade experimentais ou empíricas contam com a participação direta dos
16712855225

usuários e compreendem, basicamente, os testes com usuários por meio do


monitoramento de sessões de uso do produto, ou protótipo, em consideração.
Em geral, os testes de usabilidade com a participação dos usuários são avaliações
confiáveis.

Comentários:

Perfeito, é exatamente isso!

Gabarito: C

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 76 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

61. (CESPE - 2011 – MEC - Analista de Sistemas) Os testes de usabilidade avaliam a


facilidade de uso do software testado e são bastante utilizados em aplicações
web.

Comentários:

Perfeito, é exatamente isso!

Gabarito: C

(CESPE - 2011 - BRB - Analista de Tecnologia da Informação) O teste de regressão


tem o objetivo de localizar defeitos na estrutura interna do produto, exercitando,
suficientemente, os possíveis caminhos de execução do sistema.

Comentários:

Não, isso seria o Teste de Caminho Básico.

Gabarito: E

(CESPE - 2010 – TJ/ES - Analista de Sistemas) O teste de caixa-preta é utilizado


quando uma nova versão do software está sendo lançada ou quando um novo
ciclo de testes for necessário em paralelo ao desenvolvimento do mesmo.

Comentários:

Na verdade, isso é um Teste de Regressão, que é um teste de caixa-branca.

16712855225

Gabarito: E

64. (CESPE - 2010 – INMETRO - Analista de Sistemas) Um teste de regressão pode


ser o primeiro teste a ser realizado no software.

Comentários:

Não, isso é impossível! Teste de Regressão é aplicado em novas versões, portanto


ele não pode ser o primeiro teste a ser realizado.

Gabarito: E

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 77 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(CESPE - 2010 – TRE/BA - Analista de Sistemas) Falha é o resultado de um ou


mais defeitos em algum aspecto do sistema. No teste de regressão, caso um
novo componente ou as suas alterações, quando acrescentados aos
componentes restantes do sistema, resultem em novos defeitos em
componentes inalterados, então considera-se que o sistema regrediu.

Comentários:

Perfeito, é exatamente isso!

Gabarito: C

(CESPE - 2010 – TRE/BA - Analista de Sistemas) Se um software já testado receber


modificações e, após isso, somente essas modificações forem testadas, a
aplicação do teste de regressão a esse software testará inclusive as partes que
não tenham sido modificadas.

Comentários:

Perfeito, o Teste de Regressão testará tudo!

Gabarito: C

67. (CESPE - 2010 - ABIN - Oficial Técnico de Inteligência - Área de Desenvolvimento


e Manutenção de Sistemas) Para a verificação de resultados de um protótipo de
sistema, podem-se utilizar testes back-to-back, nos quais os mesmos casos de
teste são submetidos ao protótipo e ao sistema em teste a fim de se produzir
um relatório de diferenças.
16712855225

Comentários:

Perfeito, Testes Back-to-Back são utilizados para comparação do comportamento


das versões diferentes do mesmo software.

Gabarito: C

(CESPE - 2009 - CEHAP- - Analista de Sistemas - A) O teste gama envolve a


liberação do sistema a uma série de clientes potenciais que concordam em usar
esse sistema.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 78 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Comentários:

Na verdade, esse é o Teste Beta.

Gabarito: E

(CESPE - - CEHAP- - Analista de Sistemas - B) O teste alfa, conhecido


como teste de aceitação, encerra-se quando cliente e projetista concordam que
o sistema é uma implementação aceitável dos requisitos do sistema e não se
aplica a sistemas desenvolvidos para um único cliente.

Comentários:

Testes Beta somente são utilizados quando o sistema é desenvolvido para ser
utilizado por múltiplos usuários, caso contrário não faria sentido fazê-los. De acordo
com Sommerville: “O teste de aceitação é algumas vezes chamado de teste alfa. Os
sistemas sob encomenda são desenvolvidos para um único cliente. O processo de
teste alfa continua até que o projetista do sistema e o cliente concordem que o sistema
liberado é uma implementação aceitável dos requisitos do sistema. Quando um
sistema será comercializado como um produto de software, frequentemente é usado
um processo de teste denominado teste beta”.

Gabarito: E

70. (CESPE - 2010 – INMETRO - Analista de Sistemas - A) O teste alfa pode ser usado
para a verificação do software, mas este tipo de teste não é adequado para o
processo de validação.

Comentários: 16712855225

Os Testes Alfa são geralmente utilizados para verificação e Testes Beta para
validação. No entanto, eventualmente pode-se utilizar os Testes Alfa para validação.

Gabarito: E

71. (CESPE - 2010 – TRE/MT - Analista de Sistemas - D) O teste alfa é conduzido


pelo cliente em seu ambiente de uso final.

Comentários:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 79 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Não, a questão trata do Teste Beta.

Gabarito: E

72. (CESPE - 2004 – SESPA/PA - Analista de Sistemas) Para efeito de validação de


um software, o beta teste é realizado pelo cliente usuário do software em um
ambiente controlado, normalmente nas instalações do desenvolvedor.

Comentários:

Testes Alfa são feitos em ambiente controlado e Testes Beta são feitos em ambiente
real.

Gabarito: E

73. (CESPE - 2004 – STJ - Analista de Sistemas) Um software-produto, antes de ser


lançado no mercado normalmente deve ser testado por usuários reais do
sistema. Nessa etapa, configura-se a realização de beta testes.

Comentários:

Perfeito, é exatamente isso!

barito: C

74. (CESPE - 2010 – INMETRO - Analista de Sistemas) Um teste de recuperação deve


evitar que o sistema apresente falhas que interrompam o seu funcionamento.

Comentários: 16712855225

Teste algum consegue evitar isso! Ele apenas busca verificar a capacidade de
recuperação de um sistema.

Gabarito: E

75. (CESPE - 2004 – STJ - Analista de Sistemas) O teste de compatibilidade serve


para verificar se um software pode ser executado no sistema operacional Solaris.

Comentários:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 80 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Perfeito, ele permite verificar compatibilidade com sistemas operacionais.

Gabarito: C

ACERTEI ERREI

16712855225

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 81 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(FCC - 2013 - -SP - Agente de Defensoria - Analista de Sistemas) 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, é

a) provar a correção integral no programa sob teste.

b) ter alta probabilidade de detectar erros no programa sob teste.

c) ter grande redundância, a fim de testar mais de uma vez cada linha do
programa sob teste.

d) ser de alta complexidade, pois assim pode-se cobrir todo o programa sob
teste com apenas um teste.

e) ser ocultado da equipe de desenvolvimento do software, pois esta pode


querer impedir sua aplicação.

Comentários:

TESTES EXAUSTIVOS SÃO IMPOSSÍVEIS!

Testar todas as combinações de entradas e pré-condições é inviável, exceto para casos


16712855225

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.

(a) Conforme vimos em aula, nós já sabemos que é virtualmente impossível provar
a correção integral de um programa.

AGRUPEM OS DEFEITOS MAIS SENSÍVEIS!

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 82 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

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, de forma a ter alta
probabilidade de encontrar defeitos.

(b) Conforme vimos em aula, um teste deve ter alta probabilidade de encontrar
erros.

Pessoal, um bom teste é aquele que tem alta probabilidade de encontrar um erro;
aquele que não é redundante; e é aquele não deve ser nem muito simples e nem
muito complexo. Ao longo de diversos anos, a Engenharia de Software evoluiu
bastante, de modo a sugerir alguns princípios que guiam os Testes de Software.
Vejamos alguns abaixo:

(c) Conforme vimos em aula, são desejáveis testes eficientes e, não, redundantes.

Pessoal, um bom teste é aquele que tem alta probabilidade de encontrar um erro; é
aquele que não é redundante; e é aquele não deve ser nem muito simples e nem
muito complexo. Ao longo de diversos anos, a Engenharia de Software evoluiu
bastante, de modo a sugerir alguns princípios que guiam os Testes de Software.
Vejamos alguns abaixo:

(d) Conforme vimos em aula, testes de software não devem ser muito simples nem
muito complexos.

(e) Esse item não faz nenhum sentido! Inclusive, a própria Equipe de
Desenvolvimento pode realizar testes (Testes de Unidade).

Gabarito: B
16712855225

(FCC - 2012 - TRT - 6ª Região (PE) - Analista Judiciário - Tecnologia da


Informação) No que se refere a testes de software, é correto afirmar que:

a) o teste de operação é a fase onde é testada a ergonomia da interface de uso


do software.

b) o teste da caixa preta (teste funcional), baseia-se em analisar os arquivos de


log do sistema procurando por mensagens de funcionamento inconsistente.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 83 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

c) um teste bem sucedido é um teste que não encontra nenhum erro no


software.

d) o teste da caixa branca (teste estrutural), baseia-se em testar as estruturas do


código fonte, como comandos condicionais e de repetição.

e) um caso de teste é uma categoria de possíveis resultados na execução de


testes.

Comentários:

(a) Errado, o teste operacional é o aceite do sistema pelo administrador de sistemas,


que verifica o atendimento às configurações de ambiente e às rotinas de
administração, como backup, gerenciamento do usuário, etc.

(b) Errado, ela verifica 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 componente de software.

(c) Certo, um teste bem-sucedido é aquele que encontra erros! Se ele não encontrar
erros, é mais provável que o teste tenha sido mal feito. Já vimos isso milhões de
vezes em aula.

(d) Certo, essa é a definição de Teste Caixa-Branca!

(e) Errado, não são possíveis resultados, são possíveis entradas e os resultados
esperados para essas possíveis entradas. Esse era um item que podia confundir um
bocado de candidato.
16712855225

Gabarito: D

(FCC - 2011 - TRE-PE - Analista Judiciário - Análise de Sistemas Com relação


aos testes de software, é correto afirmar:

a) Um princípio muitas vezes adotado ao testar um software é o de Pareto. Ele


afirma que existe um forte desequilíbrio entre causas e efeitos, entre esforços e
resultados e entre ações e objetivos alcançados.

b) Testes sempre podem mostrar a ausência de erros.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 84 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

c) Para que o resultado de um teste de software seja confiável, é preciso garantir


que os casos de teste utilizados cubram um número reduzido de possibilidades
de execução.

d) Um software que produz saídas corretas deve ser aprovado, pois isso
demonstra que todos os erros foram corrigidos.

e) Um programador deve testar seu próprio código porque facilmente


conseguirá criar um caso de teste que rompe com a lógica de funcionamento
do seu código.

Comentários:

(a) Certo, o princípio de pareto é o 80/20, i.e., há – sim – um desequilíbrio entre


causas e efeitos, entre esforços e resultados e entre ações e objetivos alcançados,
ou seja, 20% das causas resultam em 80% dos defeitos; 20% dos esforços provocam
80% dos resultados; 20% ações resultam em 80% dos objetivos alcançados.

(b) Errado, conforme vimos em aula diversas vezes, os testes de software não
garantem a ausência de erros – jamais errem isso!

(c) Errado, um número reduzido de possibilidades de execução? Não, um número


amplo de possibilidades de execução.

(d) Errado, da mesma forma do segundo item, testes não garantem ausência de
erros. Dessa forma, se ele produziu saídas corretas, não necessariamente ele deve
ser aprovado. Muitas vezes, não foram realizados testes suficientes ou
eventualmente a qualidade dos testes foi baixa.
16712855225

(e) Errado, em geral, o melhor caminho é que outra pessoa teste o código. O próprio
programador pode construir um teste enviesado, de maneira que resulte nas saídas
esperadas.

Gabarito: A

(FCC - 1 – TRE/PE - Analista Sistemas) Com relação aos testes de software, é


correto afirmar:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 85 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

a) Um princípio muitas vezes adotado ao testar um software é o de Pareto. Ele


afirma que existe um forte desequilíbrio entre causas e efeitos, entre esforços e
resultados e entre ações e objetivos alcançados.

b) Testes sempre podem mostrar a ausência de erros.

c) Para que o resultado de um teste de software seja confiável, é preciso garantir


que os casos de teste utilizados cubram um número reduzido de possibilidades
de execução.

d) Um software que produz saídas corretas deve ser aprovado, pois isso
demonstra que todos os erros foram corrigidos.

e) Um programador deve testar seu próprio código porque facilmente


conseguirá criar um caso de teste que rompe com a lógica de funcionamento
do seu código.

Comentários:

AGRUPEM 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, de forma a ter alta
probabilidade de encontrar defeitos.

(a) Conforme vimos em aula, está perfeito! 20% dos erros causam 80% dos defeitos,
20% dos esforços gera 80% dos resultados e 20% das ações alcançam 80% dos
16712855225

objetivos.

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? I.e., há outros fatores!

(b) Conforme vimos em aula, testes nunca podem demonstrar ausência de erros.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 86 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

A meta é convencer os desenvolvedores e clientes do sistema de que o software é


bom o suficiente para o uso operacional. O teste é um processo voltado a atingir a
confiabilidade do software. Para o Teste de Validação, um teste bem-sucedido é
aquele em que o sistema funciona corretamente. Para o Teste de Defeitos, um teste
bem-sucedido é o que expõe um defeito que causa o funcionamento incorreto.

(c) Conforme vimos em aula, está incorreto! Ele deve ser amplo!

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? I.e., há outros fatores!

(d) Conforme vimos em aula, sabemos que isso é impossível.

(e) Não é recomendável que ele mesmo teste seu código, visto que dificilmente
conseguirá criar um caso que rompa com a lógica que ele mesmo criou.

Gabarito: A

(FCC - 2010 - TRF - 4ª REGIÃO - Analista Judiciário - Tecnologia da Informação


Sobre os processos de teste de software, considere:

I. Em um processo de desenvolvimento iterativo, o teste de sistema concentra-


se no teste de um incremento que será entregue ao cliente.
16712855225

II. No teste de integração é feito o planejamento de uma série de testes em que


a carga é constantemente aumentada até que o desempenho do sistema torne-
se aceitável.

III. A única meta do teste de software é descobrir falhas ou defeitos no software


que apresenta comportamento incorreto, não desejável ou em não
conformidade com sua especificação.

Está correto o que consta em:

a) I, apenas.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 87 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

b) I, II e III.
c) I e II, apenas.
d) II e III, apenas.
e) III, apenas.

Comentários:

SOMMERVILLE (8ª EDIÇÃO) – SISTEMAS DE GRANDE PORTE

Teste de Componente/Unidade
Teste de Integração
Teste de Sistema
Teste de Release
Teste de Aceitação

(a) Galera, vejam a confusão! Qual estágio de software vocês acham que se encaixa
melhor com um incremento? Teste de Integração, porque – para cada novo
incremento em um processo iterativo – há um teste de integração para verificar se
ele se comunica com as interfaces de forma consistente.

No entanto, eu disse em aula que o Sommerville (até 8ª Edição) tratava o Teste de


Sistema como Teste de Integração + Teste de Releases. E ele diz em seu livro: “Em
um processo de desenvolvimento iterativo, o teste de sistema concentra-se no teste
de um incremento que será entregue ao cliente; em um processo em cascata, o teste
de sistema concentra-se no teste de todo o sistema”.

Em outras palavras, a questão está idêntica ao que está escrito no livro. Todavia,
como o livro não faz essa distinção correta entre Teste de Integração e Teste de
Sistema, acontece toda essa confusão. Seguindo os estágios dos outros autores, fica
evidente notar que incrementos são de responsabilidade de Testes de Integração.
16712855225

(b) Errado, a questão trata dos testes de desempenho. 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.

(c) Errado. De acordo com Sommerville, são duas metas: demonstrar ao


desenvolvedor e ao cliente que o software atende aos requisitos; e descobrir falhas
ou defeitos no software que apresenta comportamento incorreto, não desejável ou
em não conformidade com sua especificação.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 88 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Gabarito: A

(FCC - 2015 – TRT/MG – Técnico Judiciário) Um técnico de TI do Tribunal


pretende prestar exame de certificação de teste de software e necessita conhecer
os sete princípios do Teste CFTL. Após um tempo de estudo ele observou o
seguinte:

Pode ocorrer o fato de um mesmo conjunto de testes que são repetidos várias
vezes não encontrar novos defeitos após um determinado momento. Para superar
esta condição, os casos de testes necessitam ser frequentemente revisados e
atualizados. Um conjunto de testes novo e diferente precisa ser escrito para
exercitar diferentes partes do software ou sistema com objetivo de aumentar a
possibilidade de encontrar mais erros.

Este princípio é corretamente denominado:

a) Ilusão da ausência de erros.


b) Agrupamento de defeitos.
c) Teste antecipado.
d) Dependência de contexto.
e) Paradoxo do pesticida.

Comentários:

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

os testes precisam ser revisitados com frequência.

Conforme vimos em aula, trata-se do Paradoxo do Pesticida.

Gabarito: E

(FCC - 2012 - TCE- - Analista de Controle Externo - Tecnologia da


Informação) Sobre teste de software considere:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 89 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

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.

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.

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

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.

Está correto o que se afirma em:

a) I, II, III e IV.


b) I, II e IV, apenas.
c) II, III e IV, apenas.
d) III e IV, apenas.
e) I e III, apenas.

Comentários:
16712855225

(I) Conforme vimos em aula, a questão está correta – apesar de não citar os Testes
de Aceitação.

Esse teste focaliza o esforço de verificação na menor unidade de projeto do software


– o componente ou módulo de software. Usando como guia a descrição de projeto
no nível de componente, caminhos de controle importantes são testados para

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 90 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

descobrir erros dentro dos limites do módulo. A complexidade relativa dos testes e os
erros que revelam são limitados pelo escopo restrito estabelecido para esse teste.

(II) Conforme vimos em aula, essa é a definição de Testes de Unidade.

As funções ou métodos individuais são os tipos mais simples de componentes e seus


testes são um conjunto de chamadas dessas rotinas com diferentes parâmetros de
entrada. Eles verificam o funcionamento de um pedaço do sistema ou software
isoladamente ou que possam ser testados separadamente, e são considerados um
apêndice ao passo de codificação.

(III) Conforme vimos em aula, está perfeito! Muitos questionam se o Teste de


Unidade pode ser realizado após a codificação. Galera, o Test-Driven Development
(TDD) recomenda que seja antes, mas nada impede que seja depois ou
simultaneamente.

O Teste de Integração é uma técnica sistemática para construir a arquitetura de


software ao mesmo tempo que conduz testes para descobrir erros associados com as
interfaces. O objetivo é construir uma estrutura de programa determinada pelo
projeto a partir de componentes testados em unidade. Muitas vezes, há uma
tendência de tentar integração não incremental.

(IV) Conforme vimos em aula, está perfeito!

Gabarito: A

(FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento e


Manutenção Analise os itens a seguir sobre as estratégias de teste para
softwares convencionais: 16712855225

I. Uma estratégia de teste que é escolhida normalmente por uma boa 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.

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 91 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

III. O teste de unidade enfoca a lógica interna de processamento e as estruturas


de dados dentro dos limites de um componente.

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.

Está correto o que consta em:

a) I, II, III e IV.


b) I e II, apenas.
c) I, II e III, apenas.
d) II, III e IV, apenas.
e) I, III e IV, apenas.

Comentários:

(I) Conforme vimos em aula, a questão está correta – apesar de não citar os Testes
de Aceitação.

Esse teste focaliza o esforço de verificação na menor unidade de projeto do software


– o componente ou módulo de software. Usando como guia a descrição de projeto
no nível de componente, caminhos de controle importantes são testados para
descobrir erros dentro dos limites do módulo. A complexidade relativa dos testes e os
16712855225

erros que revelam são limitados pelo escopo restrito estabelecido para esse teste.

(II) Conforme vimos em aula, é na menor unidade de projeto!

Ele enfoca a lógica interna de processamento e as estruturas de dados dentro dos


limites de um componente. Esse tipo de teste pode ser conduzido em paralelo para
diversos componentes. A interface de um módulo é testada para assegurar que as
informações fluam corretamente para dentro a para fora da unidade de programa
que está sendo testada.

(III) Conforme vimos em aula, é exatamente isso!

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 92 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Ele enfoca a lógica interna de processamento e as estruturas de dados dentro dos


limites de um componente. Esse tipo de teste pode ser conduzido em paralelo para
diversos componentes. A interface de um módulo é testada para assegurar que as
informações fluam corretamente para dentro a para fora da unidade de programa
que está sendo testada.

(IV) Conforme vimos em aula, Teste de Integração é o que mais testa a interface,
porém o Teste de Unidade também testa. Não há nada errado aqui!

Gabarito: E

(FCC - 2011 – TRT - Analista de Tecnologia da Informação) O teste de


componentes compostos concentra-se, principalmente, em verificar se:

a) a funcionalidade dos códigos do componente atendem aos requisitos de


negócio.

b) o sistema está atingindo a carga projetada, quando processados todos os


componentes em conjunto.

c) a interface de componente se comporta de acordo com sua especificação.

d) a versão dos componentes do sistema está de acordo com os requisitos não


funcionais.

e) a saturação sistêmica aborta a execução de um ou mais componentes.

Comentários: 16712855225

Vamos fazer um resumão? Você testa as unidades (Teste de Unidade); junta as


unidades em componentes compostos e testa suas interfaces (Teste de Componente);
junta os componentes e testa suas interações (Teste de Sistema); manda para outra
equipe verificar se está de acordo com a especificação (Teste de Release); por fim, os
clientes testam em Testes Alfa, Beta e de Aceitação.

Conforme vimos em aula, em outras palavras, testa-se a interface de componentes


para verificar se o seu comportamento está de acordo com sua especificação.
Muitos componentes em um sistema não são funções ou objetos simples, mas sim
componentes compostos constituídos de vários objetos que interagem.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 93 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Gabarito: C

10. (FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento e


Manutenção) 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:

a) da engenharia de sistemas.
b) do projeto do software.
c) dos códigos do programa.
d) dos requisitos funcionais.
e) dos requisitos não funcionais.

Comentários:

A imagem acima mostra que a espiral se inicia em sentido horário pelo Teste de
Unidade, que é responsável por analisar o código em si; em seguida realiza o Teste
de Integração, que é responsável por analisar o projeto; depois o Teste de
Validação/Aceitação, que é responsável por analisar os requisitos do usuário; e, por
fim, o Teste de Sistema, é responsável por analisar o sistema como um todo.

Conforme vimos em aula, trata-se do projeto de software. No entanto, essa questão


tem um pequeno deslize! Ela trata de tipos de testes e, na verdade, seria estágios
ou estratégias de testes.

Gabarito: B

11. (FCC - 2010 - TRT - 20ª REGIÃO (SE) - Analista Judiciário - Tecnologia da
16712855225

Informação) 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:

a) do desenvolvedor.
b) independente.
c) de integração.
d) de sistema.
e) unitário.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 94 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Comentários:

Inicialmente, os testes focalizam cada componente individualmente, garantindo que


ele funcione adequadamente como uma unidade, daí o nome Teste de Unidade. O
Teste de Unidade usa intensamente técnicas de teste com caminhos específicos na
estrutura de controle de um componente para garantir a cobertura completa e a
máxima detecção de erros.

Conforme vimos em aula, 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

12. (FCC - - SEFAZ- - Agente Fiscal de Rendas - Tecnologia da Informação


- Prova 3 Garantir que um ou mais componentes de um sistema combinados
funcionam corretamente é o objetivo do tipo de teste:

a) de sistema.
b) de integração.
c) de configuração.
d) operacional.
e) funcional.

Comentários:

 Teste de Integração: seu objetivo é combinar módulos e testá-los como um grupo


para verificar se funcionam de modo correto (logo, é dependente de outros
16712855225

módulos); em geral, trata-se tanto de um teste caixa-branca como de um teste


caixa-preta e se concentra em testes funcionais.

Conforme vimos em aula, trata-se do Teste de Integração.

Gabarito: B

13. (FCC - - TRT - 18ª Região (GO) - Analista Judiciário - Tecnologia da


Informação) 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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 95 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

a) sistema.
b) unidade.
c) validação.
d) arquitetura.
e) integração.

Comentários:

O Teste de Integração é uma técnica sistemática para construir a arquitetura de


software ao mesmo tempo que conduz testes para descobrir erros associados com as
interfaces. O objetivo é construir uma estrutura de programa determinada pelo
projeto a partir de componentes testados em unidade. Muitas vezes, há uma
tendência de tentar integração não incremental.

Conforme vimos em aula, trata-se do Teste de Integração.

Gabarito: E

14. (FCC - – MPE/MA - Analista Judiciário - Tecnologia da Informação No RUP,


o tipo de teste que é tratado na disciplina de Implementação e não é tratado na
disciplina de Teste é o teste de:

a) unidade.
b) integração.
c) regressão.
d) sistema.
e) aceitação.
16712855225

Comentários:

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. Geralmente são feitos pelos próprios
desenvolvedores e, não, por especialistas em testes. Por meio de Testes de Unidade,
é possível encontrar problemas mais cedo; facilita mudanças; simplifica integrações;
auxilia a documentação; melhora o projeto do software; entre outros.

Conforme vimos em aula, trata-se do Teste de Unidade. A questão envolve RUP,


mas busca avaliar se você sabe que, geralmente, testes de unidade ocorrem na fase
de codificação e, não, na fase de testes.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 96 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Gabarito: A

15. (FCC - – TRT/15 - Analista Judiciário - Tecnologia da Informação Os testes


de integração têm por objetivo verificar se:

a) os módulos testados produzem os mesmos resultados que as unidades


testadas individualmente.
b) os módulos testados suportam grandes volumes de dados.
c) as funcionalidades dos módulos testados atendem aos requisitos.
d) os valores limites entre as unidades testadas individualmente são aceitáveis.
e) o tempo de resposta dos módulos testados está adequado.

Comentários:

Acredito que os únicos itens que podem gerar alguma dúvida são: A e C! Ela gerou
uma boa polêmica! Por que o primeiro está errado? Bem, partamos do princípio de
que módulo é um conjunto de unidades. Dito isso, não faz nenhum sentido que
módulos produzam os mesmos resultados que unidades. Por que o terceiro está
certo? Bem, esse item foi extremamente genérico, mas não está errado – as
funcionalidades dos módulos testados atendem aos requisitos.

Gabarito: C

16. (FCC - 2008 - METRÔ- - Analista Treinee - Análise de Sistemas Um critério de


teste de software baseado no fluxo de dados de aplicação pode ser utilizado
como uma técnica de teste baseada:

a) na especificação. 16712855225

b) no código.
c) em falhas.
d) no uso da aplicação.
e) na intuição e experiência do engenheiro.

Comentários:

Raciocinemos: uma maneira de analisar o fluxo de dados da aplicação é analisar seu


código-fonte! Logo, trata-se de uma Técnica de Teste baseada em Código!

Gabarito: B

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 97 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

17. (FCC - - TRE-PI - Técnico Judiciário - Programação de Sistemas 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:

a) da Caixa-branca.
b) da Caixa-cinza.
c) da Caixa-preta.
d) de Integração.
e) de Regressão.

Comentários:

Código-fonte? Teste Caixa-Branca!

Gabarito: A

18. (FCC – 2014 – TRT/1 – Analista de Sistemas) Considerando o teste de software,


há o chamado teste de unidade, que consiste em testar:

a) o software completo, incluindo todos os seus componentes ou módulos, no


ambiente de testes.
b) o funcionamento dos compiladores que estiverem sendo utilizados no
desenvolvimento do software.
c) individualmente, componentes ou módulos de software que, posteriormente
devem ser testados de maneira integrada.
d) o software completo em seu ambiente final de operação, já com o hardware
16712855225

base do projeto.
e) apenas componentes ou módulos de software cujo código fonte tenha mais
de 100 linhas.

Comentários:

(a) Software completo? Incluindo todos os seus componentes ou módulos? No


ambiente de testes? Isso é um Teste Alfa!

(b) Testes de Unidade não têm nenhuma relação com funcionamento de


compiladores;

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 98 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(c) Perfeito, testam-se componentes e módulos individualmente e, posteriormente,


testa-se em conjunto no Teste de Integração;

(d) Software completo? Em seu ambiente final de operação? Com o hardware base
do projeto? Isso é um Teste Beta!

(e) Esse item não faz o menor sentido! Não é porque é um Teste de Unidade que
ele é pequeno – não há relação com a quantidade de linhas.

Gabarito: C

19. (FCC - - TRT - 3ª Região (MG) - Analista Judiciário - Tecnologia da


Informação NÃO se trata de uma técnica para testar software o teste de:

a) caixa preta.
b) regressão.
c) desempenho.
d) unidade.
e) carga

Comentários:

Observem que a ÚNICA opção que contém uma Técnica de Teste de software é a
primeira (Caixa-Preta). Teste de Unidade é Nível ou Estratégia de Teste e o restante
é Tipo de Teste. Portanto, essa questão tem quatro respostas, mas a FCC considerou
que a correta é a quarta opção. Obrigado, FCC ¬¬

16712855225

Gabarito: D

(FCC - 2010 - TRT - 9ª REGIÃO (PR) - Técnico Judiciário - Tecnologia da


Informação A técnica de teste de software, também chamada de
comportamental, é a técnica de:

a) caixa-preta.
b) caixa-branca.
c) ciclo.
d) condição.
e) fluxo de dados.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 99 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Comentários:

Teste Caixa-Preta! Testam-se as funcionalidades ou comportamento do sistema.

Gabarito: A

21. ( - 2011 - TRT - 14ª Região (RO e AC) - Técnico Judiciário - Tecnologia da
Informação Garantir o funcionamento correto do software para atender as
expectativas do cliente é o objetivo da homologação de sistemas. Nessa fase,
que precede à implantação, os testes mais comuns são os testes:

a) funcionais, de usabilidade e de aceitação.


b) de unidade, de iteração e de Integração.
c) de volume, de integridade e de aceitação.
d) da caixa-branca, de carga e de configuração.
e) de unidade, de carga e de integridade.

Comentários:

Trata-se dos testes funcionais, de usabilidade e de aceitação.

Gabarito: A

(FCC - - TRT - 16ª REGIÃO (MA) - Analista Judiciário - Tecnologia da


Informação Há um tipo de teste que vislumbra a "destruição do programa" por
meio de sua submissão a quantidades, frequências ou volumes anormais que é
o teste:

a) de recuperação. 16712855225

b) de configuração.
c) beta.
d) de desempenho.
e) de estresse.

Comentários:

Essa ficou fácil: Teste de Estresse!

Gabarito: E

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 100 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(FCC - - MPE-SE - Analista do Ministério Público – Especialidade Análise de


Sistemas A execução de um sistema com o objetivo de encontrar falhas sob
condições que demandam recursos em quantidade, frequência ou volume
anormais é definida como:

a) payload.
b) teste de estresse.
c) teste de desempenho.
d) latência da falha.
e) workload.

Comentários:

Testes de Estresse!

Gabarito: B

24. (FCC - 2011 - TCE-PR - Analista de Controle – Informática) Segundo Sommerville,


após um sistema ser completamente integrado, é possível testar propriedades
como a de desempenho do sistema. Neste contexto, considere:

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

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

III. Para determinar se o desempenho está sendo atingido, pode ser necessário
a construção de um perfil operacional, que é a listagem de todo o grupo de
operadores/usuários que farão uso deste sistema.

Está correto o que se afirma em:

a) I, apenas.
b) I, II, III.
c) III, apenas.
d) I e II, apenas.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 101 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

e) II e III, apenas.

Comentários:

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. Ele deve ser
projetado para assegurar que o sistema pode operar na carga necessária, envolvendo,
geralmente, o planejamento de uma série de testes em que a carga é constantemente
aumentada até que o desempenho se torne inaceitável.

Define-se um perfil operacional, que é um conjunto de testes que refletem uma


combinação real de trabalho a que o sistema será submetido. Esses testes geralmente
ocorrem paralelamente ao teste de carga, avaliando a capacidade de resposta do
sistema em determinadas configurações.

(I) Conforme vimos em aula, está perfeito.

(II) Conforme vimos em aula, esse teste concentra-se tanto em demonstrar que o
sistema atende aos requisitos como em descobrir problemas e defeitos no sistema.

(III) Conforme vimos em aula, o perfil operacional é um conjunto de testes que


refletem uma combinação real de trabalho a que o sistema será submetido.

Gabarito: A
16712855225

(FCC - 2012 - TRT - 6ª Região (PE) - Analista Judiciário - Tecnologia da


Informação - I) Sobre testes de sistemas, considere:

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.

II. Testes de desenvolvimento incluem testes unitários, nos quais são testados
objetos e métodos específicos; testes de componentes, nos quais são testados

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 102 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

diversos grupos de objetos; testes de sistema, nos quais são testados sistemas
parciais e sistemas completos.

III. Os testes de usuário podem ser divididos em três fases: teste alfa, em que os
usuários do software trabalham com a equipe de desenvolvimento para efetuar
testes no local do desenvolvedor; teste beta, em que um release de software é
disponibilizado aos usuários para que possam experimentar e levantar os
problemas descobertos com os desenvolvedores do sistema; teste de sistema,
em que os clientes testam um sistema para decidir se ele está pronto para ser
implantado no ambiente de trabalho.

Está correto o que se afirma em:

a) I, II e III.
b) II, apenas.
c) I e II, apenas.
d) III, apenas.
e) II e III, apenas.

Comentários:

(I) Pela bilionésima vez, nenhum teste é capaz de garantir que não restam erros em
um sistema. Já sacaram, não é?

Percebam que o discurso mudou nessa nova versão. Ele afirma, por exemplo, que
existem três níveis de granularidade para Testes de Desenvolvimento: Testes de
Unidade, Testes de Componente e Testes de Sistema. O primeiro testa unidades
individuais, com foco na funcionalidade de objetos ou métodos. O segundo testa
componentes (que são um conjunto de unidades individuais).
16712855225

Esse teste deve se concentrar em testar a interface de componentes. Por fim, o último
testa a interação de componentes que trabalham como um todo. Professor, qual a
diferença entre um Teste de Sistema e um Teste de Release? A diferença é que Teste
de Sistema busca defeitos no sistema como um todo e é realizado pela equipe de
desenvolvimento.

SOMMERVILLE (9ª EDIÇÃO)

Teste de Teste de Unidade

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 103 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Desenvolvimento Teste de Componente


Teste de Sistema
Teste de Release
Teste de Usuário

(II) Conforme vimos em aula, está perfeito (de acordo com Sommerville 9ª Edição).

(III) Conforme vimos em aula, esses não são testes de sistema, mas testes de
aceitação.

Gabarito: B

(FCC - 2010 – TRT/9 - Analista de Sistemas) O teste de sistema que força o


software a falhar de diversos modos e verifica o retorno do processamento
dentro de um tempo pré-estabelecido é um tipo de teste de:

a) Integração.
b) Estresse.
c) Recuperação.
d) Desempenho.
e) Segurança.

Comentários:

Trata-se do Teste de Recuperação!

Gabarito: C

27. (FCC - 09 – AFR/SP - Analista de Sistemas) O teste de ameaça normalmente


16712855225

deve ser aplicado dentro de um projeto de software nas etapas de:

a) teste de integração e teste de sistema.


b) desenvolvimento inicial e desenvolvimento intermediário.
c) desenvolvimento intermediário e teste de aceitação.
d) desenvolvimento intermediário e teste de sistema.
e) teste de integração e teste de aceitação.

Comentários:

TESTES DE SEGURANÇA

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 104 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Algumas vezes chamado de Testes de Ameaça, trata-se de um teste que verifica se os


mecanismos de proteção incorporados a um sistema vão, de fato, protegê-lo de invasão
indevida. Geralmente ocorrem durante os Testes de Integração e Testes de Sistema.

Conforme vimos em aula, ele é considerado um tipo de Teste de Segurança e


ocorrem durante as fases de Teste de Integração e Teste de Sistema. No entanto,
percebam que é possível responder essa questão por bom senso. Ora,
desenvolvimento inicial e desenvolvimento intermediário são etapa de teste de
software? Não, eliminamos três itens! Faz sentido ela ocorrer na etapa de Teste de
Aceitação? Claro que não, ela já tem que ter ocorrido. Sobra a Letra A!

Gabarito: A

(FCC - 09 – AFR/SP - Analista de Sistemas) Garantir que um ou mais


componentes de um sistema combinados funcionam corretamente é o objetivo
do tipo de teste:

a) funcional.
b) de sistema.
c) de integração.
d) de configuração.
e) operacional.

Comentários:

Para Sommerville, Testes de Integração e Testes de Release – são componentes do


16712855225

Teste de Sistema (em sistemas complexos). O Teste de Integração trata do esforço de


verificação em uma combinação de componentes para checar se eles funcionam
corretamente juntos, conforme as especificações. Busca encontrar defeitos nas
interfaces e nas interações entre componentes ou sistemas integrados.

Conforme vimos em aula, essa é função dos Testes de Integração.

Gabarito: C

(FCC - 2012 – AFTM/SP - Analista de Sistemas) Sobre testes de software e


avaliação de qualidades de testes é INCORRETO afirmar que:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 105 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

a) testes podem anunciar a presença de defeitos em um programa e podem


demonstrar que não existem defeitos remanescentes.

b) teste de aceitação é um processo de teste de usuário no qual o objetivo é


decidir se o software é bom o suficiente para ser implantado e usado em seu
ambiente operacional.

c) testes de desenvolvimento são de responsabilidade da equipe de


desenvolvimento de software, enquanto outra equipe deve ser responsável por
testar o sistema antes que ele seja liberado para os clientes.

d) testes de desenvolvimento incluem testes unitários, nos quais são testados


objetos e métodos específicos.

e) sempre que possível é recomendado escrever testes automatizados. Os testes


são incorporados em um programa que pode ser executado cada vez que uma
alteração é feita para um sistema.

Comentários:

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, mas mesmo se
nenhum defeito for encontrado não quer dizer que ele não os tenha.

16712855225

(a) Conforme vimos em aula, testes não podem demonstrar que não existem
defeitos remanescentes.

Quando é construído um software personalizado para um cliente, são feitos Testes


de Aceitação para permitir ao cliente validar todos os requisitos e decidir se ele é bom
o suficiente para ser implantado. Conduzido pelo usuário final e não por engenheiros
de software, um Teste de Aceitação pode variar de um informal test driver até uma
série de testes planejados e sistematicamente executados.

(b) Conforme vimos em aula, está perfeito.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 106 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

Os Testes de Desenvolvimento são aqueles em que a equipe de desenvolvimento testa


o sistema durante o desenvolvimento para descobrir bugs e defeitos. Projetistas e
programadores serão os prováveis envolvidos no processo de testes. Os Testes de
Release são aqueles em que uma equipe de testes separada testa uma versão
completa do sistema antes de ele ser liberado para os usuários.

(c) Conforme vimos em aula, está perfeito.

SOMMERVILLE (9ª EDIÇÃO)

Teste de Unidade
Teste de
Teste de Componente
Desenvolvimento
Teste de Sistema
Teste de Release
Teste de Usuário

(d) Conforme vimos em aula, está perfeito.

(e) Perfeito! Eles são essenciais para realização de Testes de Regressão. Pensem
assim, toda alteração pode causar algum defeito – os testes automatizados ajudam
a descobrir esses possíveis defeitos após cada alteração.

Gabarito: A

(FCC - 2013 – DPE/SP - Analista de Sistemas) Para aplicações convencionais, o


software é testado a partir de duas perspectivas diferentes: a lógica interna do
programa é exercitada usando técnicas de projeto de caso de teste ...I... e os
16712855225

requisitos de software são exercitados usando técnicas de projeto de casos de


teste ...II... .

O teste ...I... fundamenta-se em um exame rigoroso do detalhe procedimental.


Os caminhos lógicos do software e as colaborações entre componentes são
testados exercitando conjuntos específicos de condições e/ou ciclos.

O teste ...II... faz referência a testes realizados na interface do software. Esse tipo
de teste examina alguns aspectos fundamentais de um sistema, com pouca
preocupação em relação à estrutura lógica interna do software.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 107 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

As lacunas I e II são preenchidas correta e respectivamente, com:

a) de caminho básico - caixa-de-vidro


b) alfa - beta
c) caixa branca - caixa preta
d) de ciclo - de usabilidade
e) unitário - de interface

Comentários:

A Técnica Caixa-Branca (também conhecida como Estrutural, Programático,


Orientada à Lógica ou Caixa- -Vidro) analisa caminhos lógicos possíveis de serem
executados, portanto é necessário ter conhecimento sobre o funcionamento interno
dos componentes. Ela busca garantir que todos os caminhos independentes de um
módulo sejam executados pelo menos uma vez.

Deriva casos de teste a partir da especificação de requisitos, ignorando detalhes de


implementação e se focando nas saídas geradas em resposta a entradas escolhidas
e condições especificadas. Baseia-se em pré e pós-condições; geralmente utilizada no
fim do processo de testes e busca erros de comportamento, desempenho, inicialização
e término, interface, etc; além de funções incorretas ou inexistentes.

Conforme vimos em aula, trata-se do Teste Caixa-Branca e do Teste Caixa-Preta.

Gabarito: C

31. (FCC - 2015 – TCM/GO - Analista de Sistemas) Um Auditor de Controle Externo


do Tribunal de Contas dos Municípios do Estado de Goiás da área de TI indicou
a seguinte estratégia convencional para testes de um sistema que está sendo
16712855225

desenvolvido:

I. Para cada componente ou módulo, testar a interface, a estrutura de dados


local, os caminhos independentes ao longo da estrutura de controle e as
condições-limite para garantir que a informação flui adequadamente para
dentro e para fora do módulo, que todos os comandos tenham sido executados
e que todos os caminhos de manipulação de erros sejam testados.

II. Aplicar uma abordagem incremental de testes para a construção da


arquitetura do sistema, de forma que os módulos testados sejam integrados a

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 108 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

partir do módulo de controle principal e os testes sejam conduzidos à medida


que cada componente é inserido.

O Auditor indicou em I e II, respectivamente, os testes de:

a) caixa branca e de caixa preta, que são suficientes para validar todo o sistema.

b) unidade e de integração; na sequência, indicou os testes de validação e de


sistema que são adequados para validar todo o sistema.

c) unidade e de interoperabilidade; na sequência, indicou os testes de caixa


branca e de caixa preta que são adequados para validar todo o sistema.

d) carga e de desempenho; na sequência, indicou os testes de usabilidade e


interoperabilidade que são adequados para validar todo o sistema.

e) caixa preta e de caixa branca, que são suficientes para validar todo o sistema.

Comentários:

Ele enfoca a lógica interna de processamento e as estruturas de dados dentro dos


limites de um componente. Esse tipo de teste pode ser conduzido em paralelo para
diversos componentes. A interface de um módulo é testada para assegurar que as
informações fluam corretamente para dentro a para fora da unidade de programa
que está sendo testada.

Teste de Integração é uma técnica sistemática para construir a arquitetura de


software ao mesmo tempo que conduz testes para descobrir erros associados com
as interfaces. O objetivo é construir uma estrutura de programa determinada pelo
16712855225

projeto a partir de componentes testados em unidade. Muitas vezes, há uma


tendência de tentar integração não incremental.

Conforme vimos em aula, o primeiro é o Teste de Unidade e o segundo é o Teste


de Integração. Além disso, os testes de validação e sistema são realmente
adequados para validar todo sistema.

Gabarito: B

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 109 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(FCC - 2015 – TCM/GO - Analista de Sistemas Um Auditor de Controle Externo


do Tribunal de Contas dos Municípios do Estado de Goiás da Área de TI recebeu
a tarefa de identificar testes que sejam capazes de verificar:

− a validade funcional do sistema;


− o comportamento e o desempenho do sistema;
− quais classes de entrada vão constituir bons casos de teste;
− se o sistema é sensível a certos valores de entrada;
− quais taxas e volumes de dados o sistema pode tolerar;
− que efeito combinações específicas de dados terão na operação do sistema.

A indicação correta do Auditor é utilizar:

a) testes de caixa branca.


b) mais de um tipo de teste, pois não há um único tipo de teste capaz de avaliar
todas estas situações.
c) um tipo diferente de teste para cada uma das situações elencadas.
d) testes de caixa preta.
e) testes de desempenho para os 2 primeiros e de carga para os demais.

mentários:

Galera, apenas o Teste Caixa-Preta já seria suficiente, porque ele cumpre todos os
requisitos! Não é necessário conhecer a estrutura interna para realizar nenhum
desses testes. Além disso, não faz sentido fazer testes de desempenho para verificar
a validade funcional do sistema.

Gabarito: D
16712855225

ACERTEI ERREI

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 110 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

LISTA DE EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)


QUALIDADE DE SOFTWARE

(FCC – 2014 – TRT/1 – Analista de Sistemas) A qualidade de software constitui-se


em um fator de grande importância no seu desenvolvimento. Dentre as
propriedades utilizadas para determinar a qualidade de software,

a) mede-se, exclusivamente, a qualidade da documentação produzida para o


software.

b) verifica-se a satisfação de requisitos estabelecidos, incluindo o desempenho.

c) não se abrange questões relativas à interface do software.

d) não há preocupação com a facilidade de manutenção do software.

e) não se inclui a confiabilidade esperada do software.

(FCC – – AFR/SP – Analista de Sistemas Na prática de garantia de


qualidade de software, contrapondo com o controle de qualidade de software,
se aplica a atividade:

a) Definir planos de desenvolvimento de teste.


b) Executar teste de software.
c) Desenvolver casos de teste.
d) Definir métricas e medição.
e) Definir estratégias de testes.

(CESPE – 2010 – SERPRO - Analista de Sistemas A garantia de qualidade tem


16712855225

como objetivo testar os produtos de software de modo a identificar, relatar e


remover os defeitos encontrados, enquanto o controle da qualidade provê a
gerência sênior da organização com a visibilidade apropriada sobre o processo
de desenvolvimento.

(CESPE – 2010 – SERPRO - Analista de Sistemas) Um processo de gerenciamento


da qualidade do projeto tipicamente visa garantir e controlar a qualidade. No
controle da qualidade, são executadas atividades planejadas e sistemáticas
visando garantir que o projeto empregará os processos necessários para atender
aos requisitos. Por sua vez, a garantia da qualidade, diferentemente do controle

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 111 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

de qualidade, monitora resultados do projeto a fim de determinar se eles estão


de acordo com os padrões relevantes de qualidade e procura identificar meios
para eliminar as causas de resultados que sejam insatisfatórios.

16712855225

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 112 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

LISTA DE EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)


VERIFICAÇÃO & VALIDAÇÃO

(Instituto Cidades – 2012 - CEMIG - Agente de Gestão Administrativa - Analista


de Sistemas - A) O teste é uma atividade de verificação e validação do software
e consiste na análise dinâmica do mesmo, isto é, na execução do produto de
software com o objetivo de verificar a presença de defeitos no produto e
aumentar a confiança de que o mesmo está correto.

(CESPE - 2012 – Anatel – Analista Administrativo – quitetura de Soluções)


Considere as informações abaixo em relação ao desenvolvimento de sistemas:

I. executar um software com o objetivo de revelar falhas, mas que não prova a
exatidão do software.
II. correta construção do produto.
III. Construção do produto certo.

Correspondem corretamente a I, II e III, respectivamente,

a) Validação, verificação e teste.


b) Verificação, teste e validação.
c) Teste, verificação e validação.
d) Validação, teste e verificação.
e) Teste, validação e verificação.

(CESPE - 2010 – TJ/ES – Analista Judiciário – Analista de Sistemas) Verificação e


validação são atividades da análise de software, necessárias para se identificar o
que o software precisa executar, seguida de uma avaliação do usuário quanto às
16712855225

atividades definidas.

(CESPE - – TRT 5ª – Analista Judiciário – Analista de Sistemas) A diferença


entre verificação e validação reside no fato de que a primeira se refere ao
conjunto de atividades que garante que o software realiza corretamente uma
função específica, enquanto a segunda refere-se a um conjunto diferente de
atividades que garante que o software que foi construído é rastreável às
exigências do cliente.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 113 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(ESAF - – MPOG – Analista de Planejamento – Analista de Sistemas - B)


Demonstrar ao desenvolvedor e ao cliente que o software atende aos requisitos
é uma meta de validação do software.

(CESPE - 2008 – IPEA – Analista de Sistemas) A verificação assegura que o


produto, como fornecido, irá atender o seu uso pretendido, ou seja, que se está
construindo o produto certo. E a validação confirma que os produtos de trabalho
refletem de forma apropriada os requisitos que foram especificados, ou seja, que
se está construindo o produto corretamente.

(FCC - 2009 – AFR/SP - Analista de Sistemas) O processo de confirmação que


um software vai ao encontro das especificações de software se trata de um
conceito-chave de qualidade denominado:

a) Confiabilidade.
b) Validação.
c) Verificação.
d) Precisão.
e) Acurácia.

(CESPE - 2010 – TRE/ES - Analista de Sistemas) O teste de validação tem por


finalidade encontrar defeitos e inconsistências no programa com relação a sua
especificação.

(FCC - 2013 – ALERN - Analista de Sistemas) O teste de software é destinado a


mostrar que um programa faz o que é proposto a fazer e a descobrir seus
defeitos antes do uso. O processo de teste tem dois objetivos distintos:

1. Demonstrar ao desenvolvedor e ao cliente que o software atende a seus


16712855225

requisitos.

2. Descobrir situações em que o software se comporta de maneira incorreta,


indesejável ou de forma diferente das especificações.

Desse modo, é correto afirmar que:

a) não é objetivo final dos processos de verificação validar os requisitos de


especificação que não reflitam os desejos ou necessidades dos clientes.

b) os testes podem mostrar a presença de erros e sua ausência.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 114 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

c) o objetivo de todo teste é verificar se ele atende apenas aos requisitos


funcionais.

d) verificação e validação não são a mesma coisa em relação a testes de sistema.

e) os testes podem demonstrar que um determinado software está livre de


defeitos.

16712855225

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 115 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

LISTA DE EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)


ERRO, FALTA, FALHA E DEFEITO

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

(IADES - 2012 - EBSERH- Analista de Informática) Segundo Pressman (2011), a


definição de defeito de software é um problema de qualidade encontrado,

(a) Somente após a liberação de uso do software para os usuários finais.


(b) Antes de o software ser liberado aos usuários finais.
16712855225

(c) Na fase de revisão.


(d) Na fase de levantamento de requisitos.
(e) Na fase de prototipação.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 116 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

LISTA DE EXERCÍCIOS COMENTADOS (CESPE)


TESTES DE SOFTWARE

(CESPE - 2015 – TCU - Analista de Sistemas Os casos de testes são especificações


acerca das entradas para o teste e da saída esperada e englobam, também, uma
declaração do que está sendo testado. Devido ao tamanho do espaço de
possibilidades de teste, a geração automática exaustiva de casos de testes que
exploram todas as entradas e saídas para qualquer configuração de teste é
impossível ou computacionalmente intratável.

(CESPE - 2010 – SAD/PE – Analista de Sistemas) A respeito do plano de teste, um


registro do processo de planejamento de testes de software, assinale a opção
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 execução de um caso de teste


de software.

c) A automação de um teste de integração é mais facilmente empreendida que


a de um teste de módulo.

d) A produção de scripts de teste deve preceder a eventual construção de casos


de teste.

e) Ao se inspecionar o conteúdo de um plano de testes, devem-se encontrar,


16712855225

entre outras, as seguintes descrições: escopo de testes, abordagens de teste,


recursos para realização dos testes e cronograma das atividades de teste a serem
realizadas.

(CESPE - 1 – MEC – Analista de Sistemas) Ao ser estabelecido, um plano de


testes necessita de diversos insumos, sendo um deles a estratégia de testes.

(CESPE - 2011 – MEC – Analista de Sistemas) Na definição do documento


referente ao plano de testes, devem ser incluídos os tipos e a metodologia dos
testes. No entanto, critérios de aceitação e processos associados fogem ao
escopo desse documento e devem ser inseridos na análise dos riscos.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 117 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(CESPE - 2011 – TJ/ES – Analista de Sistemas) Conforme o RUP, o plano de teste,


artefato da disciplina de teste de responsabilidade do testador, reúne as
informações necessárias para planejar e controlar o esforço de teste referente a
uma iteração específica ou ao projeto e, entre outros itens, deve conter o tipo
de teste a ser realizado, sua estratégia e as ferramentas necessárias para sua
execução.

(CESPE - 2011 – TJ/ES – Analista de Sistemas) No plano de teste, um documento


de nível gerencial, definem-se como o teste vai ser realizado, quem vai executar
os testes, o prazo estimado e o nível de qualidade esperado.

(CESPE - 2007 – TSE – Analista de Sistemas – D) Entre os artefatos produzidos


por um processo de teste, têm-se os casos de teste. Um caso de teste é uma
situação real de uso, pois não pode ser sintetizado a partir de parâmetros
predefinidos.

(CESPE - – MPE/RR – Analista de Sistemas) No Processo Unificado, um


modelo de teste é tipicamente composto por casos de teste, os quais podem
especificar como testar cenários específicos de casos de uso. Os casos de teste
tipicamente especificam entradas, resultados esperados e outras condições
relevantes para as verificações dos cenários.

(CESPE - 2011 – MEC – Analista de Sistemas) Na etapa de execução, os roteiros


dos testes são insumos necessários, que descrevem a relação dos casos de testes
e a previsão de execução.

10. (CESPE - 2011 – MEC – Analista de Sistemas) A elaboração de scripts para teste
é um dos insumos necessários na etapa de planejamento.
16712855225

11. (CESPE - 2011 – MEC – Analista de Sistemas) Em um projeto de teste, após ser
concluída a etapa de execução, inicia-se a etapa de entrega, cujos produtos
incluem o relatório de não conformidades.

12. (CESPE - 2011 – MEC – Analista de Sistemas) A etapa de planejamento pode ser
verificada por testes estáticos e ter a documentação do sistema revisada.

13. (CESPE - 2011 – MEC – Analista de Sistemas) Na etapa de especificação, ocorrem


a elaboração e a revisão dos casos de testes.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 118 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

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

15. (CESPE - 2011 - MEC - Gerente de Projetos) Para qualquer sistema,


independentemente do seu tamanho, as etapas de teste devem seguir a seguinte
sequência: testes de componente, testes de integração e testes de sistema.

16. (CESPE - – TSE - Analista de Sistemas – C) Os testes são realizados em


várias fases de um desenvolvimento. Testes de unidade são de baixo nível, testes
de sistema são executados após os de integração, testes beta empregam apenas
desenvolvedores.

17. (CESPE - 2010 – MPE/TO - Analista de Sistemas) Entre os diversos níveis possíveis
de testes de software, há os chamados testes de unidade (Unit Tests), que
procuram testar o programa como um todo, dentro de um contexto totalmente
integrado, procurando validar todas as suas potencialidades de forma unificada.

18. (CESPE - 2010 – TJ/ES - Analista de Sistemas) No teste de unidade, o software é


forçado a falhar de diversos modos a fim de verificar se os requisitos funcionais
foram adequadamente implementados. As unidades, sejam funções,
procedimentos, métodos ou classes, são testadas duas a duas. Nesse teste,
espera-se identificar erros relacionados a algoritmos incorretos ou mal
implementados, estruturas de dados incorretas ou simples erros de
programação.

19. (CESPE - 2013 - MPU - Analista - Desenvolvimento de Sistemas) Para se avaliar


a documentação do projeto do software, deve ser utilizado o teste de unidade.
16712855225

(CESPE - 2012 - MPE-PI - Analista Ministerial - Informática - Cargo 6) Os testes


de unidade são feitos por equipes especializadas em testes, de forma a se
garantir que os módulos que compõem o sistema sob construção estejam
funcionando de acordo com as especificações.

21. (CESPE - 2011 - BRB - Analista de Tecnologia da Informação) Os testes de


unidade, normalmente feitos pelos próprios desenvolvedores, sem necessidade
de processos muito formais, são tratados dentro do próprio fluxo de
implementação por meio de métodos simplificados.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 119 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

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

(CESPE - – IPEA - Analista de Sistemas) Os testes de integração verificam


se os componentes do sistema funcionam em conjunto, se os componentes são
chamados corretamente e se os componentes transferem dados corretos via
suas interfaces. Nesses testes, os componentes são testados interligados; podem
ser necessários drivers e stubs para simular componentes ainda não
implementados; e, em sistemas de software orientados a objeto, os stubs podem
ser classes.

24. (CESPE - – TRE/PR - Analista de Sistemas) Nos testes de integração,


realizados antes dos testes unitários, os componentes são construídos e testados
separadamente.

(CESPE - 2011 - Correios - Analista de Correios - Analista de Sistemas -


Desenvolvimento de Sistemas) Em um teste de integração, é possível detectar
possíveis falhas provenientes da integração interna dos componentes de um
sistema. O teste de integração sucede o teste de unidade, no qual os módulos
são testados individualmente, e antecede o teste de sistema, em que o sistema
completo é testado.

(CESPE - 2013 – ANTT - Analista de Sistemas) O teste de aceitação pode utilizar


um processo chamado de teste alfa e beta, sendo conduzido por
desenvolvedores e podendo contar com a participação do usuário. O teste alfa
é realizado em ambiente real e o beta em ambiente controlado.
16712855225

27. (CESPE - 2009 – TRE/PR - Analista de Sistemas) O teste de aceitação envolve a


integração de dois ou mais componentes que implementam funções ou
características do sistema. Existem duas fases distintas de teste do sistema: testes
de integração e teste de caixa de vidro.

(CESPE - – TRE/PR - Analista de Sistemas) Requisitos descrevem um acordo


ou contrato entre duas partes, especificando, entre outros aspectos, o que o
sistema de software deve fazer para ser aprovado em um teste de aceitação.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 120 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(CESPE - – TCU - Analista Judiciário - Tecnologia da Informação O teste de


integração consiste em construir gradualmente o sistema, por integração de seus
componentes, e testar o sistema resultante, buscando identificar e analisar
problemas originados a partir das interações entre esses componentes, em um
ambiente de execução com características próximas àquelas a serem utilizadas
no ambiente operacional real.

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

31. (CESPE - – IPEA - Analista de Sistemas) O teste caixa-preta ou


comportamental, aplicado no início do processo de teste, é embasado nos
requisitos funcionais do software. Identifica, entre outros, erros de iniciação e
término, erros de estrutura de dados, erros de interface e funções incorretas ou
omitidas.

(CESPE - – TRE/BA - Analista de Sistemas) A figura a seguir ilustra


esquematicamente a técnica estrutural de teste de software (ou teste caixa-
branca), que avalia o comportamento interno do componente de software,
atuando diretamente sobre o código-fonte do componente para realizar testes
de condição, de fluxo de dados, de ciclos e de caminhos lógicos.

16712855225

(CESPE - – TRE/PR - Analista de Sistemas) Enquanto o teste caixa-preta é


estrutural ou orientado à lógica, o teste caixa-branca é funcional, orientado a
dado ou orientado a entrada e saída.

34. (CESPE - – TRE/PR - Analista de Sistemas) Entre os tipos de testes de caixa


preta, encontram-se o teste baseado em grafos; o particionamento de
equivalência; a análise de valor-limite; e o teste de matriz ortogonal.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 121 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(CESPE - 2010 - ABIN - Oficial Técnico de Inteligência - Área de Desenvolvimento


e Manutenção de Sistemas) Nos testes de caixa branca, o código-fonte do
programa é usado para identificar testes de defeitos potenciais, particularmente
no processo de validação, o qual demonstra se um programa atende a sua
especificação.

(CESPE - - CEHAP- - Analista de Sistemas - C) Aplicado ao final do


processo de teste, o teste caixa-preta ou comportamental é baseado nos
requisitos funcionais do software.

37. (CESPE - - CEHAP- - Analista de Sistemas - C) O teste de caixa-preta


tenta encontrar erros das seguintes categorias: funções incorretas ou omitidas,
erros de interface, erros de estrutura de dados ou de acesso a base de dados
externa, erros de comportamento ou desempenho e erros de iniciação e
término.

(CESPE - 2010 - INMETRO - Analista de Sistemas - E) Os testes caixa preta (Black


Box) avaliam as cláusulas de código, a lógica interna do componente codificado,
as configurações e outros elementos técnicos.

(CESPE - 2010 - INMETRO - Analista de Sistemas - C) Testes de caixa preta são


usualmente fundamentados na análise do código de um programa. Por outro
lado, entre as técnicas de teste não relacionadas a testes de caixa preta, estão
aquelas embasadas na intuição do testador, em especificações comportamentais
e no uso.

40. (CESPE - 2010 - SERPRO - Analista de Sistemas - C) Com relação ao emprego de


diferentes técnicas para a realização de testes de software, é correto afirmar que
haverá maior diminuição da dependência de acesso às especificações
16712855225

arquiteturais de um sistema se o testador empregar a técnica de caixa-branca


(white-box), em vez das técnicas de caixa-cinza (gray-box) e de caixa-preta
(black-box).

41. (CESPE - 2011 - MEC - Analista de Sistemas) O teste denominado caixa-preta é


utilizado para verificar se os requisitos do software são atendidos, sem verificar
o código ou a lógica do componente testado.

42. (CESPE - 2011 - MEC - Analista de Sistemas) O teste caixa-branca ou teste de


caixa de vidro é um método de projeto de casos de teste que usa a estrutura de
controle do projeto procedimental para derivar casos de teste. Dessa maneira

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 122 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

garante-se que todos os caminhos independentes de um módulo tenham sido


exercitados pelo menos uma vez, já que erros lógicos e pressupostos incorretos
são inversamente proporcionais à probabilidade de que um caminho de
programa vai ser executado.

43. (CESPE - 2010 - INMETRO - Analista de Sistemas) Os testes caixa branca (White
Box) verificam a funcionalidade e a aderência aos requisitos, em uma ótica
externa ou do usuário, sem que se tenha qualquer conhecimento do código e
da lógica interna do componente testado.

44. (CESPE - 2010 – INMETRO - Analista de Sistemas) O teste de caminho básico é


uma técnica que identifica as rotinas normalmente usadas, deixando de lado as
rotinas eventualmente executadas.

45. (CESPE - 2010 – TRE/ES - Analista de Sistemas) O teste de partições caracteriza-


se por ser um projeto de caso de teste, em que o conhecimento da estrutura do
programa é utilizado para projetar testes que verificam todas as partes desse
programa.

46. (CESPE - 2013 - MPU - Analista - Desenvolvimento de Sistemas) Testes funcionais


são aplicados para identificar não conformidades entre o programa e seus
requisitos.

47. (CESPE - 2012 - ANAC - Analista Administrativo - Área 4) Os testes funcionais


são caracterizados pelo uso do sistema conforme o seu usuário regular o faria.

48. (CESPE - 2012 - MPE-PI - Analista Ministerial - Informática - Cargo 6) Em teste


funcional, o conjunto de valores de entrada válidos pode ser reduzido por meio
de partição em classes de equivalência, o que torna a quantidade de dados de
16712855225

entrada finita.

49. (CESPE - 2011 - MEC - Gerente de Projetos) Quando o objetivo é testar uma
funcionalidade, assegurando-se que, para todo tipo de entrada, a saída
observada corresponda àquela esperada, pode-se alcançar esse objetivo
fazendo-se uso de testes do tipo caixa-branca.

(CESPE - 2010 - TRE-BA - Técnico Judiciário - Programação de Sistemas) Teste


funcional é uma técnica para se projetar casos de teste na qual o programa ou
sistema é considerado uma caixa-preta e, para testá-lo, são fornecidas entradas
e avaliadas as saídas geradas.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 123 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

51. (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 - 2006 – TSE - Analista de Sistemas) Um teste de unidade pode ser


projetado usando-se uma estratégia caixa branca. Nesse caso, há um foco nos
mecanismos internos da unidade sendo testada. A realização de testes caixa
branca pode ser apoiada por métricas de cobertura.

(CESPE - 2013 - MPU - Técnico - Tecnologia da Informação e Comunicação) Para


realizar testes de unidade ou estrutural, pode-se utilizar uma representação
conhecida como grafo de fluxo de controle de um programa. A partir do grafo,
executam-se todos os caminhos do programa, principalmente na presença de
laços.

54. (CESPE - 2010 – TJ/ES - Analista de Sistemas) O teste de integração, a exemplo


do teste caixa-branca, focaliza o esforço de validação na menor unidade de
projeto do software e, com o uso de técnicas de componentização, caminhos de
controle relevantes são testados para descobrir erros dentro dos limites do
componente.

(CESPE - 2010 - MPU - Analista de Informática - Desenvolvimento de Sistemas)


O teste de integração geralmente é um processo de teste de caixa-preta no qual
os testes são derivados da especificação do sistema, cujo comportamento pode
ser determinado por meio do estudo de suas entradas e saídas.
16712855225

(CESPE - 2013 - INPI - Analista de Planejamento - Desenvolvimento e


Manutenção de Sistemas) De modo geral, o teste de release é um processo de
teste do tipo caixa-branca em que as funcionalidades são verificadas e validadas
mediante a avaliação interna dos módulos.

57. (CESPE - 2013 – TRT.17 - Analista de Sistemas) O teste de carga, que verifica o
funcionamento do software, utiliza uma grande quantidade de usuários
simultaneamente.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 124 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(CESPE - – PMV - Analista de Sistemas) O teste de usabilidade em um sítio


da Web tem como objetivo identificar problemas de usabilidade e coletar dados
relacionados ao desempenho e às preferências dos usuários.

(CESPE - – Hemobrás - Analista de Sistemas) Teste de usabilidade consiste


na análise de um website por um grupo de experts em usabilidade.

(CESPE - – Hemobrás - Analista de Sistemas) As técnicas de avaliação de


usabilidade experimentais ou empíricas contam com a participação direta dos
usuários e compreendem, basicamente, os testes com usuários por meio do
monitoramento de sessões de uso do produto, ou protótipo, em consideração.
Em geral, os testes de usabilidade com a participação dos usuários são avaliações
confiáveis.

61. (CESPE - 2011 – MEC - Analista de Sistemas) Os testes de usabilidade avaliam a


facilidade de uso do software testado e são bastante utilizados em aplicações
web.

(CESPE - 2011 - BRB - Analista de Tecnologia da Informação) O teste de regressão


tem o objetivo de localizar defeitos na estrutura interna do produto, exercitando,
suficientemente, os possíveis caminhos de execução do sistema.

(CESPE - 2010 – TJ/ES - Analista de Sistemas) O teste de caixa-preta é utilizado


quando uma nova versão do software está sendo lançada ou quando um novo
ciclo de testes for necessário em paralelo ao desenvolvimento do mesmo.

64. (CESPE - 10 – INMETRO - Analista de Sistemas) Um teste de regressão pode


ser o primeiro teste a ser realizado no software.
16712855225

(CESPE - 2010 – TRE/BA - Analista de Sistemas) Falha é o resultado de um ou


mais defeitos em algum aspecto do sistema. No teste de regressão, caso um
novo componente ou as suas alterações, quando acrescentados aos
componentes restantes do sistema, resultem em novos defeitos em
componentes inalterados, então considera-se que o sistema regrediu.

(CESPE - 2010 – TRE/BA - Analista de Sistemas) Se um software já testado receber


modificações e, após isso, somente essas modificações forem testadas, a
aplicação do teste de regressão a esse software testará inclusive as partes que
não tenham sido modificadas.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 125 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

67. (CESPE - 2010 - ABIN - Oficial Técnico de Inteligência - Área de Desenvolvimento


e Manutenção de Sistemas) Para a verificação de resultados de um protótipo de
sistema, podem-se utilizar testes back-to-back, nos quais os mesmos casos de
teste são submetidos ao protótipo e ao sistema em teste a fim de se produzir
um relatório de diferenças.

(CESPE - 2009 - CEHAP- - Analista de Sistemas - A) O teste gama envolve a


liberação do sistema a uma série de clientes potenciais que concordam em usar
esse sistema.

(CESPE - - CEHAP- - Analista de Sistemas - B) O teste alfa, conhecido


como teste de aceitação, encerra-se quando cliente e projetista concordam que
o sistema é uma implementação aceitável dos requisitos do sistema e não se
aplica a sistemas desenvolvidos para um único cliente.

70. (CESPE - 2010 – INMETRO - Analista de Sistemas - A) O teste alfa pode ser usado
para a verificação do software, mas este tipo de teste não é adequado para o
processo de validação.

71. (CESPE - 2010 – TRE/MT - Analista de Sistemas - D) O teste alfa é conduzido


pelo cliente em seu ambiente de uso final.

72. (CESPE - 2004 – SESPA/PA - Analista de Sistemas) Para efeito de validação de


um software, o beta teste é realizado pelo cliente usuário do software em um
ambiente controlado, normalmente nas instalações do desenvolvedor.

73. ESPE - 2004 – STJ - Analista de Sistemas) Um software-produto, antes de ser


lançado no mercado normalmente deve ser testado por usuários reais do
16712855225

sistema. Nessa etapa, configura-se a realização de beta testes.

74. (CESPE - 2010 – INMETRO - Analista de Sistemas) Um teste de recuperação deve


evitar que o sistema apresente falhas que interrompam o seu funcionamento.

75. (CESPE - 2004 – STJ - Analista de Sistemas) O teste de compatibilidade serve


para verificar se um software pode ser executado no sistema operacional Solaris.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 126 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

16712855225

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 127 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

LISTA DE EXERCÍCIOS COMENTADOS (FCC)


TESTES DE SOFTWARE

(FCC - 2013 - -SP - Agente de Defensoria - Analista de Sistemas) 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, é

a) provar a correção integral no programa sob teste.

b) ter alta probabilidade de detectar erros no programa sob teste.

c) ter grande redundância, a fim de testar mais de uma vez cada linha do
programa sob teste.

d) ser de alta complexidade, pois assim pode-se cobrir todo o programa sob
teste com apenas um teste.

e) ser ocultado da equipe de desenvolvimento do software, pois esta pode


querer impedir sua aplicação.

(FCC - 2012 - TRT - 6ª Região (PE) - Analista Judiciário - Tecnologia da


Informação) No que se refere a testes de software, é correto afirmar que:

a) o teste de operação é a fase onde é testada a ergonomia da interface de uso


do software.
16712855225

b) o teste da caixa preta (teste funcional), baseia-se em analisar os arquivos de


log do sistema procurando por mensagens de funcionamento inconsistente.

c) um teste bem sucedido é um teste que não encontra nenhum erro no


software.

d) o teste da caixa branca (teste estrutural), baseia-se em testar as estruturas do


código fonte, como comandos condicionais e de repetição.

e) um caso de teste é uma categoria de possíveis resultados na execução de


testes.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 128 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(FCC - 2011 - TRE-PE - Analista Judiciário - Análise de Sistemas) Com relação


aos testes de software, é correto afirmar:

a) Um princípio muitas vezes adotado ao testar um software é o de Pareto. Ele


afirma que existe um forte desequilíbrio entre causas e efeitos, entre esforços e
resultados e entre ações e objetivos alcançados.

b) Testes sempre podem mostrar a ausência de erros.

c) Para que o resultado de um teste de software seja confiável, é preciso garantir


que os casos de teste utilizados cubram um número reduzido de possibilidades
de execução.

d) Um software que produz saídas corretas deve ser aprovado, pois isso
demonstra que todos os erros foram corrigidos.

e) Um programador deve testar seu próprio código porque facilmente


conseguirá criar um caso de teste que rompe com a lógica de funcionamento
do seu código.

(FCC - 1 – TRE/PE - Analista Sistemas) Com relação aos testes de software, é


correto afirmar:

a) Um princípio muitas vezes adotado ao testar um software é o de Pareto. Ele


afirma que existe um forte desequilíbrio entre causas e efeitos, entre esforços e
resultados e entre ações e objetivos alcançados.

b) Testes sempre podem mostrar a ausência de erros.


16712855225

c) Para que o resultado de um teste de software seja confiável, é preciso garantir


que os casos de teste utilizados cubram um número reduzido de possibilidades
de execução.

d) Um software que produz saídas corretas deve ser aprovado, pois isso
demonstra que todos os erros foram corrigidos.

e) Um programador deve testar seu próprio código porque facilmente


conseguirá criar um caso de teste que rompe com a lógica de funcionamento
do seu código.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 129 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

(FCC - 2010 - TRF - 4ª REGIÃO - Analista Judiciário - Tecnologia da Informação


Sobre os processos de teste de software, considere:

I. Em um processo de desenvolvimento iterativo, o teste de sistema concentra-


se no teste de um incremento que será entregue ao cliente.

II. No teste de integração é feito o planejamento de uma série de testes em que


a carga é constantemente aumentada até que o desempenho do sistema torne-
se aceitável.

III. A única meta do teste de software é descobrir falhas ou defeitos no software


que apresenta comportamento incorreto, não desejável ou em não
conformidade com sua especificação.

Está correto o que consta em:

a) I, apenas.
b) I, II e III.
c) I e II, apenas.
d) II e III, apenas.
e) III, apenas.

(FCC - 2015 – TRT/MG – Técnico Judiciário) Um técnico de TI do Tribunal


pretende prestar exame de certificação de teste de software e necessita conhecer
os sete princípios do Teste CFTL. Após um tempo de estudo ele observou o
seguinte:

Pode ocorrer o fato de um mesmo conjunto de testes que são repetidos várias
16712855225

vezes não encontrar novos defeitos após um determinado momento. Para superar
esta condição, os casos de testes necessitam ser frequentemente revisados e
atualizados. Um conjunto de testes novo e diferente precisa ser escrito para
exercitar diferentes partes do software ou sistema com objetivo de aumentar a
possibilidade de encontrar mais erros.

Este princípio é corretamente denominado:

a) Ilusão da ausência de erros.


b) Agrupamento de defeitos.
c) Teste antecipado.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 130 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

d) Dependência de contexto.
e) Paradoxo do pesticida.

(FCC - 2012 - TCE- - Analista de Controle Externo - Tecnologia da


Informação) Sobre teste de software considere:

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.

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.

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

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.

Está correto o que se afirma em:

a) I, II, III e IV.


b) I, II e IV, apenas. 16712855225

c) II, III e IV, apenas.


d) III e IV, apenas.
e) I e III, apenas.

(FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento e


Manutenção) Analise os itens a seguir sobre as estratégias de teste para
softwares convencionais:

I. Uma estratégia de teste que é escolhida normalmente por uma boa 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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 131 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

fim de facilitar a integração das unidades e culmina com testes que exercitam o
sistema construído.

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.

III. O teste de unidade enfoca a lógica interna de processamento e as estruturas


de dados dentro dos limites de um componente.

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.

Está correto o que consta em:

a) I, II, III e IV.


b) I e II, apenas.
c) I, II e III, apenas.
d) II, III e IV, apenas.
e) I, III e IV, apenas.

(FCC - 2011 – TRT - Analista de Tecnologia da Informação) O teste de


componentes compostos concentra-se, principalmente, em verificar se:

a) a funcionalidade dos códigos do componente atendem aos requisitos de


negócio.

b) o sistema está atingindo a carga projetada, quando processados todos os


componentes em conjunto. 16712855225

c) a interface de componente se comporta de acordo com sua especificação.

d) a versão dos componentes do sistema está de acordo com os requisitos não


funcionais.

f) a saturação sistêmica aborta a execução de um ou mais componentes.

10. (FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento e


Manutenção) Na direção dos tipos de teste focados pela engenharia de software,

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 132 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

os testes de integração cuidam dos tópicos associados com os problemas de


verificação:

a) da engenharia de sistemas.
b) do projeto do software.
c) dos códigos do programa.
d) dos requisitos funcionais.
e) dos requisitos não funcionais.

11. (FCC - 2010 - TRT - 20ª REGIÃO (SE) - Analista Judiciário - Tecnologia da
Informação) 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:

a) do desenvolvedor.
b) independente.
c) de integração.
d) de sistema.
e) unitário.

12. (FCC - - SEFAZ- - Agente Fiscal de Rendas - Tecnologia da Informação


- Prova 3) Garantir que um ou mais componentes de um sistema combinados
funcionam corretamente é o objetivo do tipo de teste:

a) de sistema.
b) de integração.
c) de configuração.
d) operacional. 16712855225

e) funcional.

13. (FCC - - TRT - 18ª Região (GO) - Analista Judiciário - Tecnologia da


Informação) 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:

a) sistema.
b) unidade.
c) validação.
d) arquitetura.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 133 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

e) integração.

14. (FCC - 2013 – MPE/MA - Analista Judiciário - Tecnologia da Informação) No RUP,


o tipo de teste que é tratado na disciplina de Implementação e não é tratado na
disciplina de Teste é o teste de:

a) unidade.
b) integração.
c) regressão.
d) sistema.
e) aceitação.

15. (FCC - 2009 – TRT/15 - Analista Judiciário - Tecnologia da Informação) Os testes


de integração têm por objetivo verificar se:

a) os módulos testados produzem os mesmos resultados que as unidades


testadas individualmente.
b) os módulos testados suportam grandes volumes de dados.
c) as funcionalidades dos módulos testados atendem aos requisitos.
d) os valores limites entre as unidades testadas individualmente são aceitáveis.
e) o tempo de resposta dos módulos testados está adequado.

16. (FCC - 2008 - METRÔ- - Analista Treinee - Análise de Sistemas) Um critério de


teste de software baseado no fluxo de dados de aplicação pode ser utilizado
como uma técnica de teste baseada:

a) na especificação.
b) no código.
c) em falhas. 16712855225

d) no uso da aplicação.
e) na intuição e experiência do engenheiro.

17. (FCC - - TRE-PI - Técnico Judiciário - Programação de Sistemas) 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:

a) da Caixa-branca.
b) da Caixa-cinza.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 134 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

c) da Caixa-preta.
d) de Integração.
e) de Regressão.

18. (FCC – 2014 – TRT/1 – Analista de Sistemas) Considerando o teste de software,


há o chamado teste de unidade, que consiste em testar:

a) o software completo, incluindo todos os seus componentes ou módulos, no


ambiente de testes.
b) o funcionamento dos compiladores que estiverem sendo utilizados no
desenvolvimento do software.
c) individualmente, componentes ou módulos de software que, posteriormente
devem ser testados de maneira integrada.
d) o software completo em seu ambiente final de operação, já com o hardware
base do projeto.
e) apenas componentes ou módulos de software cujo código fonte tenha mais
de 100 linhas.

19. (FCC - - TRT - 3ª Região (MG) - Analista Judiciário - Tecnologia da


Informação) NÃO se trata de uma técnica para testar software o teste de:

a) caixa preta.
b) regressão.
c) desempenho.
d) unidade.
e) carga

(FCC - 2010 - TRT - 9ª REGIÃO (PR) - Técnico Judiciário - Tecnologia da


Informação) A técnica de teste de software, também chamada de
16712855225

comportamental, é a técnica de:

a) caixa-preta.
b) caixa-branca.
c) ciclo.
d) condição.
e) fluxo de dados.

21. (FCC - 2011 - TRT - 14ª Região (RO e AC) - Técnico Judiciário - Tecnologia da
Informação) Garantir o funcionamento correto do software para atender as

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 135 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

expectativas do cliente é o objetivo da homologação de sistemas. Nessa fase,


que precede à implantação, os testes mais comuns são os testes:

a) funcionais, de usabilidade e de aceitação.


b) de unidade, de iteração e de Integração.
c) de volume, de integridade e de aceitação.
d) da caixa-branca, de carga e de configuração.
e) de unidade, de carga e de integridade.

(FCC - - TRT - 16ª REGIÃO (MA) - Analista Judiciário - Tecnologia da


Informação) Há um tipo de teste que vislumbra a "destruição do programa" por
meio de sua submissão a quantidades, frequências ou volumes anormais que é
o teste:

a) de recuperação.
b) de configuração.
c) beta.
d) de desempenho.
e) de estresse.

(FCC - - MPE-SE - Analista do Ministério Público – Especialidade Análise de


Sistemas) A execução de um sistema com o objetivo de encontrar falhas sob
condições que demandam recursos em quantidade, frequência ou volume
anormais é definida como:

a) payload.
b) teste de estresse.
c) teste de desempenho.
d) latência da falha. 16712855225

e) workload.

24. (FCC - 11 - TCE-PR - Analista de Controle – Informática) Segundo Sommerville,


após um sistema ser completamente integrado, é possível testar propriedades
como a de desempenho do sistema. Neste contexto, considere:

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 136 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

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

III. Para determinar se o desempenho está sendo atingido, pode ser necessário
a construção de um perfil operacional, que é a listagem de todo o grupo de
operadores/usuários que farão uso deste sistema.

Está correto o que se afirma em:

a) I, apenas.
b) I, II, III.
c) III, apenas.
d) I e II, apenas.
e) II e III, apenas.

(FCC - 2012 - TRT - 6ª Região (PE) - Analista Judiciário - Tecnologia da


Informação - I) Sobre testes de sistemas, considere:

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.

II. Testes de desenvolvimento incluem testes unitários, nos quais são testados
objetos e métodos específicos; testes de componentes, nos quais são testados
diversos grupos de objetos; testes de sistema, nos quais são testados sistemas
parciais e sistemas completos.
16712855225

III. Os testes de usuário podem ser divididos em três fases: teste alfa, em que os
usuários do software trabalham com a equipe de desenvolvimento para efetuar
testes no local do desenvolvedor; teste beta, em que um release de software é
disponibilizado aos usuários para que possam experimentar e levantar os
problemas descobertos com os desenvolvedores do sistema; teste de sistema,
em que os clientes testam um sistema para decidir se ele está pronto para ser
implantado no ambiente de trabalho.

Está correto o que se afirma em:

a) I, II e III.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 137 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

b) II, apenas.
c) I e II, apenas.
d) III, apenas.
e) II e III, apenas.

(FCC - 2010 – TRT/9 - Analista de Sistemas) O teste de sistema que força o


software a falhar de diversos modos e verifica o retorno do processamento
dentro de um tempo pré-estabelecido é um tipo de teste de:

a) Integração.
b) Estresse.
c) Recuperação.
d) Desempenho.
e) Segurança.

27. (FCC - 2009 – R/SP - Analista de Sistemas) O teste de ameaça normalmente


deve ser aplicado dentro de um projeto de software nas etapas de:

a) teste de integração e teste de sistema.


b) desenvolvimento inicial e desenvolvimento intermediário.
c) desenvolvimento intermediário e teste de aceitação.
d) desenvolvimento intermediário e teste de sistema.
e) teste de integração e teste de aceitação.

(FCC - – AFR/SP - Analista de Sistemas) Garantir que um ou mais


componentes de um sistema combinados funcionam corretamente é o objetivo
do tipo de teste:

a) funcional. 16712855225

b) de sistema.
c) de integração.
d) de configuração.
e) operacional.

(FCC - 2012 – AFTM/SP - Analista de Sistemas) Sobre testes de software e


avaliação de qualidades de testes é INCORRETO afirmar que:

a) testes podem anunciar a presença de defeitos em um programa e podem


demonstrar que não existem defeitos remanescentes.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 138 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

b) teste de aceitação é um processo de teste de usuário no qual o objetivo é


decidir se o software é bom o suficiente para ser implantado e usado em seu
ambiente operacional.

c) testes de desenvolvimento são de responsabilidade da equipe de


desenvolvimento de software, enquanto outra equipe deve ser responsável por
testar o sistema antes que ele seja liberado para os clientes.

d) testes de desenvolvimento incluem testes unitários, nos quais são testados


objetos e métodos específicos.

e) sempre que possível é recomendado escrever testes automatizados. Os testes


são incorporados em um programa que pode ser executado cada vez que uma
alteração é feita para um sistema.

(FCC - 2013 – DPE/SP - Analista de Sistemas) Para aplicações convencionais, o


software é testado a partir de duas perspectivas diferentes: a lógica interna do
programa é exercitada usando técnicas de projeto de caso de teste ...I... e os
requisitos de software são exercitados usando técnicas de projeto de casos de
teste ...II... .

O teste ...I... fundamenta-se em um exame rigoroso do detalhe procedimental.


Os caminhos lógicos do software e as colaborações entre componentes são
testados exercitando conjuntos específicos de condições e/ou ciclos.

O teste ...II... faz referência a testes realizados na interface do software. Esse tipo
de teste examina alguns aspectos fundamentais de um sistema, com pouca
preocupação em relação à estrutura lógica interna do software.
16712855225

As lacunas I e II são preenchidas correta e respectivamente, com:

a) de caminho básico - caixa-de-vidro


b) alfa - beta
c) caixa branca - caixa preta
d) de ciclo - de usabilidade
e) unitário - de interface

31. (FCC - 2015 – TCM/GO - Analista de Sistemas) Um Auditor de Controle Externo


do Tribunal de Contas dos Municípios do Estado de Goiás da área de TI indicou

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 139 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

a seguinte estratégia convencional para testes de um sistema que está sendo


desenvolvido:

I. Para cada componente ou módulo, testar a interface, a estrutura de dados


local, os caminhos independentes ao longo da estrutura de controle e as
condições-limite para garantir que a informação flui adequadamente para
dentro e para fora do módulo, que todos os comandos tenham sido executados
e que todos os caminhos de manipulação de erros sejam testados.

II. Aplicar uma abordagem incremental de testes para a construção da


arquitetura do sistema, de forma que os módulos testados sejam integrados a
partir do módulo de controle principal e os testes sejam conduzidos à medida
que cada componente é inserido.

O Auditor indicou em I e II, respectivamente, os testes de:

a) caixa branca e de caixa preta, que são suficientes para validar todo o sistema.

b) unidade e de integração; na sequência, indicou os testes de validação e de


sistema que são adequados para validar todo o sistema.

c) unidade e de interoperabilidade; na sequência, indicou os testes de caixa


branca e de caixa preta que são adequados para validar todo o sistema.

d) carga e de desempenho; na sequência, indicou os testes de usabilidade e


interoperabilidade que são adequados para validar todo o sistema.

e) caixa preta e de caixa branca, que são suficientes para validar todo o sistema.
16712855225

(FCC - 2015 – TCM/GO - Analista de Sistemas) Um Auditor de Controle Externo


do Tribunal de Contas dos Municípios do Estado de Goiás da Área de TI recebeu
a tarefa de identificar testes que sejam capazes de verificar:

− a validade funcional do sistema;


− o comportamento e o desempenho do sistema;
− quais classes de entrada vão constituir bons casos de teste;
− se o sistema é sensível a certos valores de entrada;
− quais taxas e volumes de dados o sistema pode tolerar;
− que efeito combinações específicas de dados terão na operação do sistema.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 140 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

A indicação correta do Auditor é utilizar:

a) testes de caixa branca.


b) mais de um tipo de teste, pois não há um único tipo de teste capaz de avaliar
todas estas situações.
c) um tipo diferente de teste para cada uma das situações elencadas.
d) testes de caixa preta.
e) testes de desempenho para os 2 primeiros e de carga para os demais.

16712855225

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 141 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

GABARITO DOS EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)


QUALIDADE DE SOFTWARE

1 2 3 4 5 6 7 8 9 10
B D E E

GABARITO DOS EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)


VERIFICAÇÃO & VALIDAÇÃO

1 2 3 4 5 6 7 8 9 10
C C C C C E C E D

GABARITO DOS EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)


ERRO, FALTA, FALHA E DEFEITO

1 2 3 4 5 6 7 8 9 10
E C E A

GABARITO DOS EXERCÍCIOS COMENTADOS (CESPE)


TESTES DE SOFTWARE

1 2 3 4 5 6 7 8 9 10
16712855225

C E C E E C E C C E
11 12 13 14 15 16 17 18 19 20
C E C E C E E E E E
21 22 23 24 25 26 27 28 29 30
C C C E C E E C E E
31 32 33 34 35 36 37 38 39 40
E C E C E C C E E E
41 42 43 44 45 46 47 48 49 50
C C E E E C E C E C

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 142 de 143


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 08

51 52 53 54 55 56 57 58 59 60
E C E E E E C C E C
61 62 63 64 65 66 67 68 69 70
C E E E C C C E E E
71 72 73 74 75 76 77 78 79 80
E E C E C

GABARITO DOS EXERCÍCIOS COMENTADOS (FCC)


TESTES DE SOFTWARE

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

16712855225

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