Engenharia de Software - 08 - Qualidade de Software

Prévia do material em texto

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 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 1 de 143 
 
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
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 2 de 143 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
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; 
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. 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 3 de 143 
 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. 
 
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: 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 4 de 143 
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 
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. 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 5 de 143 
 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. 
 
 
 
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 
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 
GARANTIA E CONTROLE DE QUALIDADE 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 6 de 143 
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 
é definido e apropriado. 
 
As atividades de controle da qualidade focam 
na descoberta de defeitos em i específicos. 
Metodologia e padrões de desenvolvimento 
são exemplos de garantia da qualidade. 
Um exemplo de controle da qualidade poderia 
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 
prevenção. 
 
Controle da qualidade é orientado a detecçã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 
no ciclo de vida de desenvolvimento de 
software. 
As atividades são focadas no final das fases 
no ciclo de vida de desenvolvimento de 
software. 
Garantia da qualidade garante que você está 
fazendo certo as coisas e da maneira correta. 
Controle da qualidade garante que os 
resultados do seu trabalho são os esperados 
conforme requisitos. 
 
 
 
 
 
 
 
 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 7 de 143 
 
 
 (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); 
 
(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 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 8 de 143 
 (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 – 
geralmenteocorre 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 
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 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 9 de 143 
 (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
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 10 de 143 
 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
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 11 de 143 
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 
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 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 12 de 143 
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, 
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é?! 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 13 de 143 
 
 
 (Instituto Cidades – 2012 - CEMIG - Agente de Gestão Administrativa - Analista 
de Sistemas - A) O teste é uma atividade de verificaçãoe 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, 
 
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 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 14 de 143 
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! 
 
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 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 15 de 143 
 (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: 
 
 
 
Conforme vimos em aula, trata-se claramente da Verificação. 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 16 de 143 
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. 
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. 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 17 de 143 
(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
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 18 de 143 
 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 
 
DEFEITO 
Ato inconsistente cometido por um indivíduo ao tentar entender uma 
informação, resolver um problema ou utilizar um método ou uma ferramenta. 
Pode ocasionar a manifestação de erros em um produto. 
 
ERRO 
Manifestação concreta de um defeito. Diferença entre valor obtido e valor 
esperado, i.e., estado intermediário incorreto ou resultado inesperado 
durante a execução de um programa constitui um erro. 
 
FALHA 
Comportamento operacional do software diferente do esperado pelo usuário. 
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 
 
DEFEITO 
Incapacidade de algum componente em realizar a função à qual foi projetado. 
 
 
 
ERRO 
Manifestação de uma falha no sistema, causando diferenças das respostas 
apresentadas com as esperadas – nem todas as falhas causarão erros no 
programa. 
 
FALHA 
Incapacidade de o sistema executar suas funções requeridas dentro das 
exigências especificadas – não existe falha se o programa não tem defeito. 
 
 
DE ACORDO COM PRESSMANDEFEITO 
Problema de qualidade descoberto após o software ser lançado aos usuários 
finais ou após outra atividade de um processo de software. 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 19 de 143 
 
ERRO 
Problema de qualidade descoberto antes de o software ser lançado aos 
usuários finais ou após outra atividade de um processo de software. 
 
 
FALHA 
Incapacidade de o sistema executar suas funções requeridas dentro das 
exigências especificadas – não existe falha se o programa não tem defeito. 
 
 
DE ACORDO COM SOMMERVILLE 
 
DEFEITO 
Uma característica do sistema de software que pode levar a um erro de 
sistema. Por exemplo, a falha em iniciar uma variável pode levar a um valor 
errado quando esta for usada. 
 
ERRO 
Um estado errôneo de sistema que pode levá-lo a um comportamento 
inesperado pelos seus usuários. 
 
 
FALHA 
Um evento que ocorre em algum momento, quando o sistema não fornece um 
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. 
 
 
 
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! 
UNIVERSO DO USUÁRIO 
UNIVERSO DA INFORMAÇÃO 
UNIVERSO FÍSICO 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 20 de 143 
 
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! 
 
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! =[ 
 
 
 
 
 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 21 de 143 
 
 
 (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 
 
DEFEITO 
Ato inconsistente cometido por um indivíduo ao tentar entender uma 
informação, resolver um problema ou utilizar um método ou uma ferramenta. 
Pode ocasionar a manifestação de erros em um produto. 
 
ERRO 
Manifestação concreta de um defeito. Diferença entre valor obtido e valor 
esperado, i.e., estado intermediário incorreto ou resultado inesperado 
durante a execução de um programa constitui um erro. 
 
FALHA 
Comportamento operacional do software diferente do esperado pelo usuário. 
Pode ter sido causada por diversos erros e alguns erros podem nunca causar 
uma falha. Afetam diretamente o usuário final. 
 
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: 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 22 de 143 
 
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 
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, 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 23 de 143 
 
(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 
 
DEFEITO 
Problema de qualidade descoberto após o software ser lançado aos usuários 
finais ou após outra atividade de um processo de software. 
 
 
ERRO 
Problema de qualidade descoberto antes de o software ser lançado aos 
usuários finais ou após outra atividade de um processo de software. 
 
 
FALHA 
Incapacidade de o sistema executar suas funções requeridas dentro das 
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
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 24 de 143 
 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 
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. 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 25 de 143 
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. 
 
 
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! 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 26 de 143 
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
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 27 de 143 
 
 
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 
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. 
PROCESSO DE TESTE 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 28 de 143 
 
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 
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. 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 29 de 143 
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
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 30 de 143 
 
 
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 
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, 
ESTRATÉGIA DE TESTES 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 31 de 143 
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 
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áriapara 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 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 32 de 143 
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 
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. 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 33 de 143 
 
 
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 
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. 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 34 de 143 
 
 
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: 
 
 
 
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 
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. 
 
TESTE DE UNIDADE (COMPONENTE OU MÓDULO) 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 35 de 143 
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. 
 
 
 
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 
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 
TESTE DE INTEGRAÇÃO 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 36 de 143 
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. 
 
 
 
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. 
 
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 
TESTE DE VALIDAÇÃO (ACEITAÇÃO) 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 37 de 143 
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 
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. 
 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 38 de 143 
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. 
 
 
 
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 é 
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 verificarse 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 
TESTE DE SISTEMA 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 39 de 143 
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. 
 
 
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, 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 40 de 143 
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 
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 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 41 de 143 
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 
Desenvolvimento 
Teste de Unidade 
Teste de Componente 
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). 
 
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 
16712855225
Curso Regular de Engenharia de Software 
Curso de Teoria e Exercícios - 2016 
Prof. Diego Carvalho – Aula 08 
 
 
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 42 de 143 
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.