Questão de Engenharia de Software — Conceitos e Tipos de Testes de Software — Avança SP 2023
Engenharia de Software›Conceitos e Tipos de Testes de Software
Código
qa541925
Banca
Avança SP
Órgão
CM Embu-Guaçu
Ano
2023
Cargo
ATI ( )
Qual o conceito de teste de software e suas principais fases do processo de testes?
AO teste de software é uma etapa final do desenvolvimento que visa garantir que o software esteja livre de bugs. As principais fases do processo de testes são Planejamento de Testes, Execução de Testes, Avaliação de Resultados e Documentação de Defeitos.
BO teste de software é um processo complexo de identificar erros no código e validar se o software atende aos requisitos. As fases do processo de testes incluem Teste de Unidade, Teste de Integração, Teste de Sistema e Teste de Aceitação.
CO teste de software é uma atividade simples de verificar a aparência visual do software. As principais fases do processo de testes são Projeto de Interface, Teste de Interface, Teste Funcional e Teste de Usabilidade.
DO teste de software é uma técnica que visa melhorar o desempenho do sistema. As fases do processo de testes incluem Teste de Performance, Teste de Carga, Teste de Estresse e Teste de Segurança.
EO teste de software é uma abordagem para criar casos de uso em um software. As principais fases do processo de testes são Modelagem de Casos de Uso, Execução de Casos de Uso, Avaliação de Resultados e Relatório de Defeitos.
Revelar gabarito e comentário▾
GabaritoB — O teste de software é um processo complexo de identificar erros no código e validar se o software atende aos requisitos. As fases do processo de testes incluem Teste de Unidade, Teste de Integração, Teste de Sistema e Teste de Aceitação.
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”.
Teste de Software: Conceito e Níveis de Teste
Gabarito: letra B. O teste de software é um processo sistemático de identificar erros e validar se o software atende aos requisitos, e as fases clássicas do processo de testes são os níveis: Teste de Unidade, Teste de Integração, Teste de Sistema e Teste de Aceitação. A alternativa B é a única que combina corretamente o conceito (identificar erros + validar requisitos) com os níveis de teste, que são a forma mais consagrada de organizar as fases do processo de testes.
O teste de software é uma atividade fundamental da Engenharia de Software, muito mais ampla do que simplesmente "procurar bugs" ou "verificar a aparência". Ele é um processo que envolve a execução do software com a intenção de revelar falhas, mas também de confirmar que o sistema faz o que deveria fazer. Essa dupla finalidade é essencial: de um lado, busca-se descobrir situações em que o software se comporta de maneira incorreta, indesejável ou diferente das especificações; de outro, busca-se demonstrar que o software atende aos requisitos e às expectativas do cliente. Essa visão é corroborada pela literatura clássica de Engenharia de Software, como Sommerville e Pressman, e é o que a banca espera que o candidato conheça.
As "fases" do processo de testes podem ser entendidas de duas formas complementares. A primeira, mais gerencial, envolve o planejamento, a execução, a avaliação de resultados e a documentação de defeitos — um ciclo de atividades que organiza o trabalho de testar. A segunda, mais técnica e estrutural, refere-se aos níveis de teste, que representam a progressão natural do teste à medida que o software é construído: primeiro testam-se as unidades (menores partes do código), depois a integração entre elas, depois o sistema como um todo e, por fim, a aceitação pelo usuário final. É essa segunda visão que a alternativa B adota, e é a mais cobrada em concursos quando se fala em "fases do processo de testes".
É importante distinguir níveis de teste de técnicas de teste. Os níveis dizem respeito ao escopo do que está sendo testado (uma unidade, um conjunto integrado, o sistema inteiro, ou a aceitação do cliente). As técnicas, por sua vez, dizem respeito à abordagem: se o testador enxerga o código interno (caixa branca) ou se testa apenas as entradas e saídas (caixa preta). Essa distinção é crucial porque a banca frequentemente mistura os dois conceitos para confundir o candidato. Por exemplo, o teste de unidade é um nível, mas pode ser executado com técnica de caixa branca; o teste de sistema é um nível, mas geralmente usa técnica de caixa preta. São eixos independentes.
A pegadinha desta questão está justamente na mistura desses conceitos. As alternativas A, C, D e E apresentam conceitos parciais ou equivocados de teste de software e, principalmente, listam como "fases" elementos que não são níveis de teste, mas sim tipos específicos de teste (como teste de performance, carga, estresse, segurança, usabilidade) ou atividades de outras áreas (como modelagem de casos de uso, projeto de interface). A alternativa B é a única que acerta tanto o conceito quanto as fases, apresentando os quatro níveis clássicos de teste. Guarde essa distinção entre níveis, tipos e técnicas: é exatamente nela que as alternativas se dividem.
Critério
Alternativa A
Alternativa B (Gabarito)
Alternativa C
Alternativa D
Alternativa E
Conceito de teste
Parcialmente correto (identificar bugs), mas reducionista ("etapa final")
Níveis clássicos (Unidade, Integração, Sistema, Aceitação)
Atividades de design + tipos (Projeto de Interface, Teste de Interface, Funcional, Usabilidade)
Tipos de teste não funcional (Performance, Carga, Estresse, Segurança)
Atividades de requisitos + teste (Modelagem de Casos de Uso, Execução, Avaliação, Relatório)
Adequação ao que a questão pede
❌ Não são níveis de teste
✅ São os níveis de teste
❌ Não são níveis de teste
❌ Não são níveis de teste
❌ Não são níveis de teste
1Teste de Unidade
2Teste de Integração
3Teste de Sistema
4Teste de Aceitação
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
O conceito está parcialmente correto ao mencionar a identificação de bugs, mas é reducionista ao afirmar que o teste é uma "etapa final" do desenvolvimento. O teste de software é um processo contínuo, que deve estar presente em todas as fases do desenvolvimento, não apenas no final. Além disso, as "fases" listadas (Planejamento, Execução, Avaliação e Documentação) são atividades do processo de teste, mas não são os níveis de teste que a questão cobra. A banca troca os níveis (Unidade, Integração, Sistema, Aceitação) por atividades gerenciais do processo de teste.
Alternativa B — ✅ Correta ⟵ GABARITO
Esta alternativa está correta porque define o teste de software com precisão: um processo de identificar erros no código e validar se o software atende aos requisitos. Essa é a definição clássica, que engloba tanto a verificação (o software está sendo construído corretamente?) quanto a validação (estamos construindo o produto certo?). Além disso, lista corretamente os quatro níveis de teste: Teste de Unidade (testa cada componente isoladamente), Teste de Integração (testa a interação entre componentes), Teste de Sistema (testa o sistema completo) e Teste de Aceitação (testa se o sistema atende às necessidades do cliente).
Alternativa C — ❌ Incorreta
O conceito está totalmente equivocado: o teste de software não é uma "atividade simples de verificar a aparência visual". Isso é apenas uma parte do teste de usabilidade, que é um tipo de teste, não o conceito geral. As "fases" listadas (Projeto de Interface, Teste de Interface, Teste Funcional, Teste de Usabilidade) misturam atividades de design de interface com tipos de teste, mas não são os níveis de teste. A banca confunde o teste de software com o design de interface do usuário.
Alternativa D — ❌ Incorreta
O conceito está incorreto ao afirmar que o teste de software é uma técnica para melhorar o desempenho. Melhorar o desempenho é um objetivo de otimização, não de teste. Os itens listados (Teste de Performance, Teste de Carga, Teste de Estresse, Teste de Segurança) são tipos de teste, não níveis de teste. Eles são importantes, mas não representam as fases do processo de testes. A banca troca os níveis por tipos específicos de teste não funcional.
Alternativa E — ❌ Incorreta
O conceito está incorreto: o teste de software não é uma abordagem para criar casos de uso. Criar casos de uso é uma atividade da Engenharia de Requisitos, não de teste. As "fases" listadas (Modelagem de Casos de Uso, Execução de Casos de Uso, Avaliação de Resultados, Relatório de Defeitos) misturam atividades de modelagem de requisitos com atividades de teste, mas não são os níveis de teste. A banca confunde o teste de software com a modelagem de casos de uso.
NÃO CAIA NESSA!
A banca adora misturar os níveis de teste (Unidade, Integração, Sistema, Aceitação) com os tipos de teste (Performance, Carga, Estresse, Segurança, Usabilidade) e com atividades do processo (Planejamento, Execução, Avaliação). Quando a questão pedir "fases do processo de testes", pense primeiro nos níveis — é a resposta mais clássica e mais cobrada. As alternativas C, D e E caem exatamente nessa armadilha, listando tipos ou atividades que não são níveis.
PEGA ESSA DICA!
Para não errar mais, memorize a hierarquia: Níveis (o que se testa: Unidade → Integração → Sistema → Aceitação) × Tipos (o que se verifica: funcional, performance, segurança, usabilidade) × Técnicas (como se testa: caixa preta, caixa branca). Quando a questão falar em "fases do processo de testes", a resposta quase sempre será os níveis. Quando falar em "tipos de teste", serão os tipos específicos. Essa distinção resolve a maioria das questões de teste de software em concursos.