Pular para o conteúdo principal

Questão de Engenharia de Software — Teste de Software — VUNESP 2026

Engenharia de SoftwareTeste de Software
Código
gp044432
Banca
VUNESP
Órgão
UNESP
Ano
2026
Cargo
V - - Analista de Informática I - Área de Atuação: Desenvolvimento de Sistemas - São Paulo
Considere os seguintes tipos de testes de software: I. Teste de integração II. Teste de aceitação III. Teste de unidade IV. Teste de sistema A ordem correta de execução desses quatro tipos deteste, para que o processo de testes seja adequadamente realizado, é
  1. AI, II, III e IV.
  2. BII, III, IV e I.
  3. CIII, I, IV e II.
  4. DIII, IV II e I.
  5. EIV, II, I e III.
Revelar gabarito e comentário

GabaritoC — III, I, IV e II.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Níveis de teste de software: ordem de execução

Gabarito: letra C. A ordem correta de execução dos níveis de teste é: III (unidade) → I (integração) → IV (sistema) → II (aceitação). Essa sequência reflete a progressão natural do processo de teste, que começa testando as menores unidades de código isoladamente, depois verifica a integração entre elas, em seguida valida o sistema como um todo e, por fim, confirma se o software atende às necessidades do cliente. Essa é a ordem clássica apresentada na engenharia de software, seguindo a lógica de construção do software, do menor para o maior escopo.

Os níveis de teste representam as diferentes etapas em que o software é testado, cada uma com um objetivo específico e um escopo distinto. Eles formam uma hierarquia que acompanha o desenvolvimento do software, do código-fonte até a entrega ao usuário final. Compreender essa hierarquia é fundamental para organizar um processo de teste eficaz, pois cada nível depende do anterior para ser executado adequadamente.

O teste de unidade é o primeiro nível e foca na menor parte testável do software, como uma função, método ou classe. Seu objetivo é verificar se essa unidade isolada funciona corretamente, de acordo com sua especificação interna. Geralmente, é realizado pelo próprio desenvolvedor, que conhece a estrutura interna do código. Por exemplo, ao desenvolver uma função que calcula o imposto de renda, o teste de unidade verificaria se essa função retorna o valor correto para diferentes faixas salariais.

Em seguida, o teste de integração verifica se os módulos ou unidades que já foram testados individualmente funcionam corretamente quando combinados. O foco aqui são as interfaces entre os componentes e a interação entre eles, buscando descobrir erros que só aparecem quando os módulos se comunicam. Por exemplo, após testar individualmente o módulo de cálculo de imposto e o módulo de cadastro de funcionários, o teste de integração verificaria se o sistema consegue calcular o imposto de um funcionário recém-cadastrado, garantindo que a comunicação entre os módulos está correta.

O teste de sistema avalia o software como um todo, já integrado, em um ambiente que simula o ambiente de produção. O objetivo é verificar se o sistema completo atende aos requisitos funcionais e não funcionais especificados, exercitando todas as funcionalidades de forma integrada. Por exemplo, o teste de sistema verificaria se o fluxo completo de cadastro de um funcionário, cálculo de salário e geração de holerite funciona corretamente, do início ao fim.

Por fim, o teste de aceitação é realizado pelo cliente ou usuário final, com o objetivo de validar se o software atende às suas necessidades e expectativas. É a última etapa antes da entrega e pode ser realizado em ambiente de produção ou em um ambiente controlado que simule a realidade do usuário. O teste de aceitação responde à pergunta: "o software faz o que o cliente esperava que ele fizesse?". Por exemplo, o cliente testaria o sistema de folha de pagamento para verificar se ele atende às regras de negócio específicas da sua empresa.

A ordem de execução desses níveis é crucial porque cada nível se baseia no resultado do anterior. Não faz sentido testar a integração de módulos que ainda não foram testados individualmente, pois seria difícil isolar a causa de um erro. Da mesma forma, não faz sentido testar o sistema completo sem antes verificar se as integrações estão corretas. E o teste de aceitação só deve ser realizado quando o sistema já foi validado internamente.

A banca explora a confusão entre a ordem dos níveis de teste e a ordem das fases do desenvolvimento de software. É comum o candidato confundir a sequência, invertendo a ordem do teste de sistema e do teste de aceitação, ou colocando o teste de integração antes do teste de unidade. A chave para acertar é lembrar que o teste de unidade é sempre o primeiro, pois testa a menor parte do software, e o teste de aceitação é sempre o último, pois valida o produto final com o cliente.

Guarde a sequência unidade → integração → sistema → aceitação como um fluxo lógico de crescimento de escopo: do menor componente ao sistema completo, e do ponto de vista técnico ao ponto de vista do negócio. É essa progressão que as alternativas tentam embaralhar.

  1. 1Unidade
  2. 2Integração
  3. 3Sistema
  4. 4Aceitação
LEVEL · soulevel.com.br

Alternativa A — ❌ Incorreta

A ordem I, II, III e IV (integração, aceitação, unidade e sistema) está completamente invertida. Ela começa pelo teste de integração, que deveria vir depois do teste de unidade, e coloca o teste de aceitação em segundo lugar, quando ele deveria ser o último. Essa alternativa ignora a hierarquia de escopo dos níveis de teste.

Alternativa B — ❌ Incorreta

A ordem II, III, IV e I (aceitação, unidade, sistema e integração) também está errada. Ela coloca o teste de aceitação em primeiro lugar, o que não faz sentido, pois o software ainda não está pronto para ser aceito pelo cliente. Além disso, inverte a ordem entre integração e sistema, colocando o teste de sistema antes do teste de integração.

Alternativa C — ✅ Correta ⟵ GABARITO

A ordem III, I, IV e II (unidade, integração, sistema e aceitação) é a sequência correta. Ela segue a progressão lógica de testar primeiro as unidades isoladas, depois a integração entre elas, em seguida o sistema completo e, por fim, a aceitação pelo cliente. Essa é a ordem clássica apresentada na engenharia de software.

Alternativa D — ❌ Incorreta

A ordem III, IV, II e I (unidade, sistema, aceitação e integração) começa corretamente com o teste de unidade, mas depois pula para o teste de sistema, ignorando o teste de integração. Além disso, coloca o teste de aceitação antes do teste de integração, o que não faz sentido, pois o cliente não pode aceitar um software que ainda não foi integrado e testado como um todo.

Alternativa E — ❌ Incorreta

A ordem IV, II, I e III (sistema, aceitação, integração e unidade) está completamente invertida. Ela começa pelo teste de sistema, que deveria ser um dos últimos, e coloca o teste de unidade em último lugar, quando ele deveria ser o primeiro. Essa alternativa inverte totalmente a hierarquia dos níveis de teste.

A ordem correta dos níveis de teste é um conceito fundamental da engenharia de software, e a banca explora a confusão entre eles. Lembre-se sempre da progressão: unidade → integração → sistema → aceitação. Essa sequência reflete o crescimento do escopo do teste, do menor componente ao sistema completo, e do ponto de vista técnico ao ponto de vista do negócio.

Gabarito: letra C

Link permanente: /questoes/gp044432