Title: Engenharia de Software / Testes de Software
Tags: Engenharia_de_Software Resumo
On every note of this deck, unless a note says otherwise:
tldr: - Teste de software executa o sistema para:
- Validar que atende aos requisitos/uso esperado (teste bem-sucedido = sistema funciona).
- Encontrar defeitos (teste bem-sucedido = expõe uma falha).
- Testes não provam ausência de erros (Dijkstra): apenas reduzem o risco e aumentam a confiança de que o software é “bom o suficiente”.
- Confiabilidade é medida estatisticamente: probabilidade de operar sem falhas por um tempo/ambiente (ex.: 0,999 em 8h).
- Um bom teste:
- tem alta chance de achar defeitos;
- não é redundante;
- é o “melhor da raça” quando há alternativas;
- não é simples demais nem complexo demais.
- 7 princípios (ISTQB): testes mostram presença de defeitos; exaustão é impossível; testar cedo; defeitos se concentram (Pareto); paradoxo do pesticida (precisa variar testes); depende do contexto; “zero defeitos” não garante sucesso.
- Testabilidade depende de: operabilidade, observabilidade, controlabilidade, decomponibilidade, simplicidade, estabilidade e compreensibilidade.
- Processo de testes: planejamento → preparação → especificação → execução → entrega (documentação e lições).
- Artefatos-chave: Plano de Testes (escopo, estratégia, recursos, cronograma etc.) e Casos de Teste (condições/entradas, saídas esperadas, ambiente, dependências).
- Níveis/Estratégia (do pequeno ao grande, idealmente incremental):
- Unidade (componentes isolados, geralmente por devs),
- Integração (interfaces; evitar “Big Bang”),
- Validação/Aceitação (visão do usuário; pode envolver alfa e beta),
- Sistema (sistema completo, incluindo software+hardware+pessoas+dados).
- Técnicas:
- Caixa-branca (estrutura/código e caminhos),
- Caixa-preta (funcionalidade por entradas/saídas; particionamento, valor limite etc.),
- Caixa-cinza (híbrida).
- Tipos de teste destacados: desempenho (carga/estresse), usabilidade, regressão, fumaça, comparação (back-to-back), alfa/beta, recuperação, compatibilidade, segurança e vulnerabilidade.
- Automação de testes acelera e escala (CI/CD), mas vale mais para testes repetíveis, determinísticos, tediosos e críticos; manuais são melhores para ad-hoc e funcionalidades em alta mudança.
- Boas práticas: testar cedo e com frequência; manter testes; e seguir FIRST (Fast, Isolated, Repeatable, Self-validating, Timely) em testes unitários.
- Testes de contrato (provider e CDC) garantem compatibilidade entre APIs/serviços e detectam breaking changes cedo; não substituem testes de integração.
- Em ágil: testes contínuos, colaboração, TDD/BDD, automação, CI e testes exploratórios.
- Doubles para isolar dependências: dummy, stub, mock, spy e fake (ex.: simular banco/serviço externo).
link: https://documentacao.online/estudos/w6n2.html
title: Testes de Software

front: (FCC – TRF4 – Analista Judiciário – Item III) A única meta do teste de software é descobrir falhas ou defeitos no software que apresenta comportamento incorreto, não desejável ou em não conformidade com sua especificação.
response: Errado
comment: são duas metas: demonstrar ao desenvolvedor e ao cliente que o software atende aos requisitos; e descobrir falhas ou defeitos no software que apresenta comportamento incorreto, não desejável ou em não conformidade com sua especificação (Errado).
Other fields (not shown on cards):
back: Errado - são duas metas: demonstrar ao desenvolvedor e ao cliente que o software atende aos requisitos; e descobrir falhas ou defeitos no software que apresenta comportamento incorreto, não desejável ou em não conformidade com sua especificação (Errado).

front: (DPE/SP – 2013) O teste de software constitui-se em uma etapa importante no ciclo de desenvolvimento de software. Uma das características mais importantes de um conjunto de testes de software, adequadamente planejados, é:
a) provar a correção integral no programa sob teste.
b) ter alta probabilidade de detectar erros no programa sob teste.
c) ter grande redundância, a fim de testar mais de uma vez cada linha do programa sob teste.
d) ser de alta complexidade, pois assim pode-se cobrir todo o programa sob teste com apenas um teste.
e) ser ocultado da equipe de desenvolvimento do software, pois esta pode querer impedir sua aplicação.
response: Alternativa B
comment: (a) Errado, testes exaustivos são impossíveis; (b) Correto, deve-se agrupar os defeitos mais sensíveis para aumentar a probabilidade de detectar erros no programa sob teste; (c) Errado, caso os mesmos testes sejam aplicados repetidamente, em determinado momento eles deixam de ser úteis; (d) Errado, testes de software não devem ser muito simples nem muito complexos; (e) Errado, esse item não faz qualquer sentido lógico (Letra B).
Other fields (not shown on cards):
back: Alternativa B - (a) Errado, testes exaustivos são impossíveis; (b) Correto, deve-se agrupar os defeitos mais sensíveis para aumentar a probabilidade de detectar erros no programa sob teste; (c) Errado, caso os mesmos testes sejam aplicados repetidamente, em determinado momento eles deixam de ser úteis; (d) Errado, testes de software não devem ser muito simples nem muito complexos; (e) Errado, esse item não faz qualquer sentido lógico (Letra B).

front: (TCU – 2015) Os casos de testes são especificações acerca das entradas para o teste e da saída esperada e englobam, também, uma declaração do que está sendo testado. Devido ao tamanho do espaço de possibilidades de teste, a geração automática exaustiva de casos de testes que exploram todas as entradas e saídas para qualquer configuração de teste é impossível ou computacionalmente intratável.
response: Correto
comment: casos de teste realmente são especificações das entradas para o teste e da saída esperada e englobam, também, uma declaração do que está sendo testado. A geração automática ou não de casos de teste que exploram todas as entradas e saídas para qualquer configuração de teste é impossível ou computacionalmente intratável, visto que um dos princípios fundamentais é o de que testes exaustivos são impossíveis, isto é, testar todas as combinações de entradas e pré-condições é inviável, exceto para casos triviais. Assim, é realmente inviável testar todo o espaço amostral de testes de software, exceto para casos triviais – mesmo por meio de ferramentas automatizadas (Correto).
Other fields (not shown on cards):
back: Correto - casos de teste realmente são especificações das entradas para o teste e da saída esperada e englobam, também, uma declaração do que está sendo testado. A geração automática ou não de casos de teste que exploram todas as entradas e saídas para qualquer configuração de teste é impossível ou computacionalmente intratável, visto que um dos princípios fundamentais é o de que testes exaustivos são impossíveis, isto é, testar todas as combinações de entradas e pré-condições é inviável, exceto para casos triviais. Assim, é realmente inviável testar todo o espaço amostral de testes de software, exceto para casos triviais – mesmo por meio de ferramentas automatizadas (Correto).

front: TRT/MG – 2015) Um técnico de TI do Tribunal pretende prestar exame de certificação de teste de software e necessita conhecer os sete princípios do Teste CFTL. Após um tempo de estudo ele observou o seguinte: Pode ocorrer o fato de um mesmo conjunto de testes que são repetidos várias vezes não encontrar novos defeitos após um determinado momento. Para superar esta condição, os casos de testes necessitam ser frequentemente revisados e atualizados. Um conjunto de testes novo e diferente precisa ser escrito para exercitar diferentes partes do software ou sistema com objetivo de aumentar a possibilidade de encontrar mais erros. Este princípio é corretamente denominado:
a) Ilusão da ausência de erros.
b) Agrupamento de defeitos.
c) Teste antecipado.
d) Dependência de contexto.
e) Paradoxo do pesticida.
response: Alternativa E
comment: trata-se do Paradoxo do Pesticida, isto é, 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 (Letra E).
Other fields (not shown on cards):
back: Alternativa E - trata-se do Paradoxo do Pesticida, isto é, 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 (Letra E).

front: (PROCEM/PA – 2014) O teste é parte fundamental no ciclo de vida de um software. Seus princípios devem servir como um guia geral, tanto para testadores quanto para desenvolvedores. Afinal, ambos participam efetivamente do processo de amadurecimento do sistema. Assinale a opção que apresenta corretamente três dos sete princípios fundamentais do teste de software.
a) Testes apontam a presença de falhas – Testes dependem do contexto – Testes apontam os custos
b) Depende dos requisitos – Testes apontam a presença de falhas – Paradoxo do pesticida
c) Teste antecipado – Testes apontam os custos – Ausência de erros é uma ilusão
d) Paradoxo do pesticida – Teste antecipado – Testes dependem do contexto
e) Ausência de erros é uma ilusão – Agrupamento de defeitos – Dependem dos requisitos
response: Alternativa D
comment: (a) Errado, o terceiro item não é um dos princípios fundamentais; (b) Errado, o primeiro item não é um dos princípios fundamentais; (c) Errado, o segundo item não é um dos princípios fundamentais; (d) Correto, todos são princípios fundamentais; (e) Errado, o terceiro item não é um dos princípios fundamentais (Letra D).
Other fields (not shown on cards):
back: Alternativa D - (a) Errado, o terceiro item não é um dos princípios fundamentais; (b) Errado, o primeiro item não é um dos princípios fundamentais; (c) Errado, o segundo item não é um dos princípios fundamentais; (d) Correto, todos são princípios fundamentais; (e) Errado, o terceiro item não é um dos princípios fundamentais (Letra D).

front: (FIOCRUZ – 2010) No que diz respeito aos sistemas de software, o objetivo do teste é encontrar erros, sendo um teste aquele que tem alta probabilidade de encontrar um erro. Assim, um engenheiro de software deve projetar e implementar um sistema ou um produto baseado em computador com “testabilidade” em mente. Ao mesmo tempo, os testes devem exibir um conjunto de características que atinge o objetivo de encontrar a maioria dos erros com um mínimo de esforço. Dentre as características que levam a um software testável, uma pode ser resumida pela frase “Quanto melhor funciona, mas eficientemente pode ser testado”. Se um sistema é projetado e implementado com qualidade em mente, poucos defeitos vão bloquear a execução dos testes, permitindo que o teste progrida sem problemas. Essa característica é definida como:
a) estabilidade.
b) simplicidade.
c) operabilidade.
d) controlabilidade.
e) observabilidade.
response: Alternativa C
comment: a questão trata da operabilidade - “quanto melhor funciona, mais eficientemente pode ser testado” (Letra C).
Other fields (not shown on cards):
back: Alternativa C - a questão trata da operabilidade - “quanto melhor funciona, mais eficientemente pode ser testado” (Letra C).

front: (MEC – 2011) Em um projeto de teste, após ser concluída a etapa de execução, inicia-se a etapa de entrega, cujos produtos incluem o relatório de não conformidades.
response: Correto
comment: a etapa de entrega realmente se inicia após a etapa de execução, gerando um relatório de conformidades e não- conformidades (Correto).
Other fields (not shown on cards):
back: Correto - a etapa de entrega realmente se inicia após a etapa de execução, gerando um relatório de conformidades e não- conformidades (Correto).

front: (MEC – 2011) A elaboração de scripts para teste é um dos insumos necessários na etapa de planejamento.
response: Errado
comment: a elaboração de scripts para teste é um dos insumos necessários na etapa de execução (Errado).
Other fields (not shown on cards):
back: Errado - a elaboração de scripts para teste é um dos insumos necessários na etapa de execução (Errado).

front: (MEC – 2011) Na etapa de especificação, ocorrem a elaboração e a revisão dos casos de testes.
response: Correto
comment: realmente temos as atividades de elaborar e revisar casos de testes e roteiros de testes na etapa de especificação (Correto).
Other fields (not shown on cards):
back: Correto - realmente temos as atividades de elaborar e revisar casos de testes e roteiros de testes na etapa de especificação (Correto).

front: (MEC – 2011) Na etapa de execução, os roteiros dos testes são insumos necessários, que descrevem a relação dos casos de testes e a previsão de execução.
response: Correto
comment: os roteiros de testes (scripts) realmente são insumos da etapa de execução e – de fato – descrevem a relação dos casos de teste e a previsão de execução (Correto).
Other fields (not shown on cards):
back: Correto - os roteiros de testes (scripts) realmente são insumos da etapa de execução e – de fato – descrevem a relação dos casos de teste e a previsão de execução (Correto).

front: (MEC – 2011) A implementação do ambiente de teste deve ser feita durante a preparação do processo de teste, devendo o responsável pela execução ser identificado na matriz de responsabilidades.
response: Correto
comment: organiza-se o ambiente de testes (infraestrutura, equipamentos, hardware, software, pessoal capacitado, ferramentas e massa de testes adequadas) justamente na etapa de preparação de testes (Correto).
Other fields (not shown on cards):
back: Correto - organiza-se o ambiente de testes (infraestrutura, equipamentos, hardware, software, pessoal capacitado, ferramentas e massa de testes adequadas) justamente na etapa de preparação de testes (Correto).

front: (MPE/MA – 2011) O propósito de um plano de testes é descrever o escopo, os recursos, a abordagem e o tempo alocado para as atividades de teste. Identifica os itens e funcionalidades a serem testados, os responsáveis e os riscos.
response: Correto
comment: todos esses realmente são atributos que podem ser contemplados em um plano de teste (Correto).
Other fields (not shown on cards):
back: Correto - todos esses realmente são atributos que podem ser contemplados em um plano de teste (Correto).

front: (INFRAERO – 2011) A especificação de um caso de teste (test case specification) deve conter, entre outros, identificador, itens constantes no teste, especificação de entrada, especificação de saída, definição do ambiente necessário, necessidades especiais e dependências de outros casos de testes.
response: Correto
comment: são exatamente esses itens que devem constar em um caso de teste (Correto).
Other fields (not shown on cards):
back: Correto - são exatamente esses itens que devem constar em um caso de teste (Correto).

front: (EBSERH – 2013) Os testes de software são executados, usando os procedimentos e documentos de script de teste. Para que a fase de execução de teste, seja realizada com sucesso deve(m) serexecutado(s):
a) os casos de uso
b) os diagramas de atividade
c) os casos de teste
d) os testes de Turing
e) o teste de COMA.
response: Alternativa C
comment: na fase de especificação os casos de teste são elaborados e revisados, mas eles são efetivamente executados na fase de execução (Letra C).
Other fields (not shown on cards):
back: Alternativa C - na fase de especificação os casos de teste são elaborados e revisados, mas eles são efetivamente executados na fase de execução (Letra C).

front: (UFG – 2017) Considere os diferentes níveis de teste de funcionalidade de um software. Os testes de sistema estão para a Engenharia de Sistemas, assim como:
a) os testes de integração e de validação estão, respectivamente, para o código e o projeto.
b) os testes de unidades e de integração estão, respectivamente, para os requisitos e o projeto.
c) os testes de unidades e de validação estão, respectivamente, para o código e o projeto.
d) os testes de validação e de integração estão, respectivamente, para os requisitos e o projeto.
response: Alternativa D
comment: bastava lembrar da nossa espiral. Logo, os testes de sistema estão para engenharia de sistemas, assim como os testes de validação e de integração estão, respectivamente, para requisitos e projeto (Letra D).
Other fields (not shown on cards):
back: Alternativa D - bastava lembrar da nossa espiral. Logo, os testes de sistema estão para engenharia de sistemas, assim como os testes de validação e de integração estão, respectivamente, para requisitos e projeto (Letra D).

front: (TCE/AM – 2011) Uma estratégia de teste que é escolhida por grande parte das equipes de software adota uma visão incremental do teste, começando com o teste de unidades individuais de programa, avançando para testes projetados a fim de facilitar a integração das unidades e culmina com testes que exercitam o sistema construído.
response: Correto
comment: a questão mostra exatamente o que vimos de uma abordagem incremental começando com testes de unidade e terminando com testes de sistema (Correto).
Other fields (not shown on cards):
back: Correto - a questão mostra exatamente o que vimos de uma abordagem incremental começando com testes de unidade e terminando com testes de sistema (Correto).

front: (UFC – 2016) Qual das opções abaixo contém apenas níveis de teste de software?
a) Teste de unidade, Teste de estresse, Teste de aceitação.
b) Teste de integração, Teste de estresse, Teste de sistema.
c) Teste de aceitação, Teste Chinês, Teste de caixa branca.
d) Teste de unidade, Teste de integração, Teste de aceitação.
e) Teste de sistema, Teste de caixa branca, Teste de caixa preta.
response: Alternativa D
comment: (a) Errado, Teste de Estresse não é nível de teste; (b) Errado, Teste de Estresse não é nível de teste; (c) Errado, Teste Chinês e Caixa Branca não são níveis de teste; (d) Correto, todos são níveis de teste; (e) Errado, Teste Caixa Branca e Preta não são níveis de teste (Letra D).
Other fields (not shown on cards):
back: Alternativa D - (a) Errado, Teste de Estresse não é nível de teste; (b) Errado, Teste de Estresse não é nível de teste; (c) Errado, Teste Chinês e Caixa Branca não são níveis de teste; (d) Correto, todos são níveis de teste; (e) Errado, Teste Caixa Branca e Preta não são níveis de teste (Letra D).

front: (BRB – 2011) Os testes de unidade, normalmente feitos pelos próprios desenvolvedores, sem necessidade de processos muito formais, são tratados dentro do próprio fluxo de implementação por meio de métodos simplificados.
response: Correto
comment: realmente são feitos pelos próprios desenvolvedores e de forma mais simplificada (Correto)
Other fields (not shown on cards):
back: Correto - realmente são feitos pelos próprios desenvolvedores e de forma mais simplificada (Correto)

front: (TRT20 – 2010) No contexto da estratégia para o teste de um projeto, os estágios de teste desempenham um papel importante. O teste que é aplicado a componentes do modelo de implementação para verificar se os fluxos de controle e de dados estão cobertos e funcionam conforme o esperado, é o teste:
a) do desenvolvedor.
b) independente.
c) de integração.
d) de sistema.
e) unitário.
response: Alternativa E
comment: o teste de unidade – de fato – é aplicado a componentes e busca verificar se os fluxos de controle (ordem das instruções de um algoritmo) e de dados estão cobertos e conforme o esperado (Letra E).
Other fields (not shown on cards):
back: Alternativa E - o teste de unidade – de fato – é aplicado a componentes e busca verificar se os fluxos de controle (ordem das instruções de um algoritmo) e de dados estão cobertos e conforme o esperado (Letra E).

front: (INPI – 2013) No teste de integração, verificam-se o funcionamento em conjunto dos componentes do sistema, se são chamados corretamente e se a transferência de dados acontece no tempo correto, por meio de suas interfaces.
response: Correto
comment: ele realmente verifica o funcionamento do conjunto de componentes por meio de suas interfaces (Correto).
Other fields (not shown on cards):
back: Correto - ele realmente verifica o funcionamento do conjunto de componentes por meio de suas interfaces (Correto).

front: (CET – 2011) Em um teste de integração, é possível detectar possíveis falhas provenientes da integração interna dos componentes de um sistema. O teste de integração sucede o teste de unidade, no qual os módulos são testados individualmente, e antecede o teste de sistema, em que o sistema completo é testado.
response: Correto
comment: ele realmente detecta falhas de provenientes da integração dos componentes. Além disso, é verdade que o teste de integridade sucede o teste de unidade e antecede o teste de sistema (Correto).
Other fields (not shown on cards):
back: Correto - ele realmente detecta falhas de provenientes da integração dos componentes. Além disso, é verdade que o teste de integridade sucede o teste de unidade e antecede o teste de sistema (Correto).

front: (UFRJ – 2008) O teste de validação focaliza ações e saídas tais como percebidas pelo usuário final.
response: Correto
comment: ele realmente só enfoca aquilo que é visto ou reconhecido pelo usuário (Correto).
Other fields (not shown on cards):
back: Correto - ele realmente só enfoca aquilo que é visto ou reconhecido pelo usuário (Correto).

front: (MPE/MA – 2013) O teste de aceitação normalmente é realizado utilizando-se a interface final do sistema. Sobre esse tipo de teste pode-se afirmar que tem como objetivo principal a validação do software quanto aos requisitos.
response: Correto
comment: ele faz a validação quanto aos requisitos e seus critérios de validação descritos no documento de requisitos (Correto).
Other fields (not shown on cards):
back: Correto - ele faz a validação quanto aos requisitos e seus critérios de validação descritos no documento de requisitos (Correto).

front: (ANAC – 2009) Requisitos descrevem um acordo ou contrato entre duas partes, especificando, entre outros aspectos, o que o sistema de software deve fazer para ser aprovado em um teste de aceitação.
response: Correto
comment: a questão trata dos critérios de validação/aceitação (Correto).
Other fields (not shown on cards):
back: Correto - a questão trata dos critérios de validação/aceitação (Correto).

front: (TRE/ES – 2011) O teste de validação tem por finalidade encontrar defeitos e inconsistências no programa com relação a sua especificação.
response: Errado
comment: observem que o enunciado evidentemente trata de uma comparação, logo quem tem por finalidade encontrar defeitos e inconsistências no programa em relação a sua especificação é o teste de verificação (Errado).
Other fields (not shown on cards):
back: Errado - observem que o enunciado evidentemente trata de uma comparação, logo quem tem por finalidade encontrar defeitos e inconsistências no programa em relação a sua especificação é o teste de verificação (Errado).

front: (BANRISUL – 2018) ............. é uma verificação de consistência entre o sistema de software e sua especificação e, portanto, é uma atividade de verificação feita depois que se tem o sistema completo, com todas suas partes integradas para verificar se as funcionalidades especificadas nos documentos de requisitos estão todas corretamente implementadas. Este tipo de teste é focado principalmente na descoberta de falhas e executado pelo grupo de desenvolvimento de testes, tendo também um papel importante para avaliar se o produto pode ser liberado para os consumidores, o que é diferente do seu papel de expor falhas que são removidas para melhorar o produto. Assinale a alternativa que preenche corretamente a lacuna do texto acima.
a) Teste de sistema
b) Teste de unidade
c) Inspeção
d) Teste de regressão
e) Teste de integração
response: Alternativa A
comment: a questão trata dos testes de sistema. Eles realmente verificam a consistência entre sistema e especificação, sendo uma atividade de verificação e, não, validação. Item impecável (Letra A).
Other fields (not shown on cards):
back: Alternativa A - a questão trata dos testes de sistema. Eles realmente verificam a consistência entre sistema e especificação, sendo uma atividade de verificação e, não, validação. Item impecável (Letra A).

front: (FACEPE – 2015) Assinale a alternativa que corresponde ao estágio de processo de teste de software, no qual os componentes são integrados para compor o sistema, com vistas, entre outros, à busca de erros que resultam das interações não previstas entre os componentes, problemas de interface de componentes, validação de que o sistema atende aos requisitos funcionais e não funcionais.
a) Teste de sistema
b) Teste de componente
c) Teste de aceitação
d) Teste de especificação
e) Teste de operação
response: Alternativa A
comment: a questão trata dos testes de sistema – eles buscam erros resultantes das interações e integrações do sistema como um todo e também dos problemas de interface. A questão foi tão genérica que, se houvesse a opção Teste de Integração, teríamos duas respostas (Letra A).
Other fields (not shown on cards):
back: Alternativa A - a questão trata dos testes de sistema – eles buscam erros resultantes das interações e integrações do sistema como um todo e também dos problemas de interface. A questão foi tão genérica que, se houvesse a opção Teste de Integração, teríamos duas respostas (Letra A).

front: (DATAPREV – 2012) Nesse tipo de teste, o analista tem total acesso à estrutura interna da entidade sendo analisada. Permite, por exemplo, que o analista possa escolher partes específicas de um componente para serem testadas. O tipo de teste citado é conhecido como teste:
a) Funcional
b) Caixa-preta.
c) Caixa-branca.
d) De estresse.
e) De integração.
response: Alternativa C
comment: a questão trata do teste caixa-branca – aquele em que o analista tem total acesso à estrutura interna analisada.
Other fields (not shown on cards):
back: Alternativa C - a questão trata do teste caixa-branca – aquele em que o analista tem total acesso à estrutura interna analisada.

front: (Prefeitura de Teresina – 2016) Um Analista de Sistemas da PRODATER realizou testes diretamente sobre o código fonte de um componente de software para avaliar o seu comportamento interno usando testes de condição, de fluxo de dados, de ciclos e de caminhos lógicos. O Analista aplicou técnica de teste de:
a) caixa preta.
b) caixa branca.
c) sistema.
d) integração.
e) aceitação.
response: Alternativa B
comment: trata-se do teste caixa-branca – ele possui acesso ao código fonte dos componentes e consegue avaliar o seu comportamento interno por meio de vários métodos diferentes (Letra B).
Other fields (not shown on cards):
back: Alternativa B - trata-se do teste caixa-branca – ele possui acesso ao código fonte dos componentes e consegue avaliar o seu comportamento interno por meio de vários métodos diferentes (Letra B).

front: (UFBA – 2009) Os testes de software Caixa-Branca examinam o comportamento interno do componente de software.
response: Correto
comment: a questão está perfeita – definição pura e simples de teste caixa-branca (Correto).
Other fields (not shown on cards):
back: Correto - a questão está perfeita – definição pura e simples de teste caixa-branca (Correto).

front: (TRE/PI – 2009) Também conhecido por teste estrutural ou orientado à lógica, é uma técnica de teste de software que trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos, tais como, teste de condição, teste de fluxo de dados, teste de ciclos e teste de caminhos lógicos. Trata-se da técnica de teste:
a) da Caixa-branca.
b) da Caixa-cinza.
c) da Caixa-preta.
d) de Integração.
e) de Regressão.
response: Alternativa A
comment: trata-se do teste caixa-branca – aquele que trabalha diretamente sobre o código-fonte por meio de diversos métodos, como os mencionados no enunciado (Letra A).
Other fields (not shown on cards):
back: Alternativa A - trata-se do teste caixa-branca – aquele que trabalha diretamente sobre o código-fonte por meio de diversos métodos, como os mencionados no enunciado (Letra A).

front: (UFRJ – 2009) Um teste de software que está relacionado a um exame minucioso de sua estrutura interna e detalhes procedimentais e que trabalha diretamente sobre o código fonte do software é conhecido como teste:
a) de validação;
b) de caixa-branca;
c) funcional;
d) de caixa-preta;
e) orientado a dado.
response: Alternativa B
comment: a técnica que trata do exame minucioso da estrutura interna e detalhes procedimentais é a técnica de teste caixa- branca (Letra B).
Other fields (not shown on cards):
back: Alternativa B - a técnica que trata do exame minucioso da estrutura interna e detalhes procedimentais é a técnica de teste caixa- branca (Letra B).

front: (TJ/AP – 2014) No Tribunal de Justiça do Estado do Amapá, um software está passando por um teste no qual são verificadas as suas funcionalidades sem preocupação com os detalhes de implementação. Nesse processo de teste estão sendo realizadas a identificação das funcionalidades que o software deve realizar e a criação dos casos de testes capazes de checar se essas funcionalidades estão sendo realizadas adequadamente. Trata-se do teste:
a) alfa.
b) de integração.
c) de caixa-branca.
d) de unidade.
e) de caixa-preta.
response: Alternativa E
comment: a questão afirma que se trata de um teste no qual são verificadas as suas funcionalidades sem preocupação com detalhes de implementação, logo se trata dos testes caixa-preta (Letra E)
Other fields (not shown on cards):
back: Alternativa E - a questão afirma que se trata de um teste no qual são verificadas as suas funcionalidades sem preocupação com detalhes de implementação, logo se trata dos testes caixa-preta (Letra E)

front: (TRT/PR – 2010) A técnica de teste de software, também chamada de comportamental, é a técnica de:
a) caixa-preta.
b) caixa-branca.
c) ciclo.
d) condição.
e) fluxo de dados.
response: Alternativa A
comment: teste comportamental é um teste caixa-preta (Letra A).
Other fields (not shown on cards):
back: Alternativa A - teste comportamental é um teste caixa-preta (Letra A).

front: (MPE/RO – 2012) Considerando a arquitetura de software convencional, a técnica de teste que avalia o comportamento externo do componente de software, sem considerar o seu comportamento interno, denomina-se:
a) Caixa-branca.
b) Caixa-cinza.
c) Caixa-preta.
d) Regressão.
e) Técnicas não funcionais
response: Alternativa C
comment: quem avalia o comportamento externo de um componente de software sem considerar seu comportamento interno é a técnica de teste caixa-preta (Letra C).
Other fields (not shown on cards):
back: Alternativa C - quem avalia o comportamento externo de um componente de software sem considerar seu comportamento interno é a técnica de teste caixa-preta (Letra C).

front: (CPDEMIG – 2013) Qual o tipo de teste de software contempla os requisitos comportamentais, e que permitem testar plenamente os requisitos funcionais de um programa?
a) Teste de ciclo.
b) Teste de condição.
c) Teste caixa-preta
d) Teste de fluxo.
response: Alternativa C
comment: as palavras-chave já dão uma dica: requisitos comportamentais que permitem testar plenamente os requisitos funcionais de um programa são o teste caixa-preta – lembrando que essa técnica também chamada de teste funcional ou comportamental (Letra C).
Other fields (not shown on cards):
back: Alternativa C - as palavras-chave já dão uma dica: requisitos comportamentais que permitem testar plenamente os requisitos funcionais de um programa são o teste caixa-preta – lembrando que essa técnica também chamada de teste funcional ou comportamental (Letra C).

front: (COBRA – 2015) Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido. Haverá sucesso no teste, se o resultado obtido for igual ao resultado esperado. Interessa a função executada, e não a característica interna do componente. O componente de software a ser testado pode ser um método, uma função interna, um programa, um componente, um conjunto de programas e/ou componentes ou mesmo uma funcionalidade. Trata-se de um teste:
a) Não funcional.
b) Caixa Preta.
c) Caixa Branca.
d) Ponto de Função.
e) Não estrutural.
response: Alternativa B
comment: trata-se do teste caixa-preta ou orientado à entrada/saída (Letra B).
Other fields (not shown on cards):
back: Alternativa B - trata-se do teste caixa-preta ou orientado à entrada/saída (Letra B).

front: (SERPRO – 2010) A engenharia de software é um a disciplina do conhecimento humano que aplica princípios da engenharia ao desenvolvimento de software. N o entanto, existem diferenças significativas entre as engenharias clássicas — mecânica, civil, elétrica— e a engenharia de software, muitas delas decorrentes das diferenças de natureza entre o produto ou sistema resultante da atividade das engenharias clássicas e a engenharia de software. A engenharia de software desdobrou-se em várias áreas especializadas, como as áreas de requisitos de software, de análise e projeto de software, de implementação de software, de testes de software, de gestão de configuração, entre outras. N a interface entre as engenharias clássicas e a de software insere-se a engenharia de sistemas, abordada colateralmente na ISO/IEC 12207. Com relação ao emprego de diferentes técnicas para a realização de testes de software, é correto afirmar que haverá maior diminuição da dependência de acesso às especificações arquiteturais de um sistema se o testador empregar a técnica de caixa- branca (white-box), em vez das técnicas de caixa-cinza (gray-box) e de caixa-preta (black-box).
response: Errado
comment: o teste caixa-branca depende completamente do acesso às especificações arquiteturais de um sistema, testes caixa cinza menos e testes caixa-preta necessitam apenas de pré-condições e pós-condições. Dessa forma, a questão está incorreta, tendo em vista que haverá maior menor diminuição da dependência de acesso às especificações arquiteturais de um sistema se o testador empregar a técnica de caixa-branca, em vez das técnicas de caixa-cinza e de caixa-preta (Errado).
Other fields (not shown on cards):
back: Errado - o teste caixa-branca depende completamente do acesso às especificações arquiteturais de um sistema, testes caixa cinza menos e testes caixa-preta necessitam apenas de pré-condições e pós-condições. Dessa forma, a questão está incorreta, tendo em vista que haverá maior menor diminuição da dependência de acesso às especificações arquiteturais de um sistema se o testador empregar a técnica de caixa-branca, em vez das técnicas de caixa-cinza e de caixa-preta (Errado).

front: (SERPRO – 2015) Um dos tipos de teste de software é o teste de desempenho. Um teste desse tipo:
a) corresponde a medir os tempos de processamento com falhas no hardware do sistema computacional.
b) não pode ser realizado com o sistema já em operação.
c) não se aplica a programas escritos com linguagens de programação orientadas a objetos.
d) visa apenas verificar se o software sob teste não contém erros lógicos.
e) visa assegurar se o sistema computacional pode operar sob a carga de operação especificada.
response: Alternativa E
comment: (a) Errado, não faz nenhum sentido; (b) Errado, claro que pode ser realizado com o sistema em operação; (c) Errado, pode ser aplicado em programas que utilizem quaisquer linguagens de programação; (d) Errado, esse seria um teste caixa-branca; (e) Correto, ele realmente visa assegurar que o sistema computacional pode operar sob a carga de operação especificada (Letra E).
Other fields (not shown on cards):
back: Alternativa E - (a) Errado, não faz nenhum sentido; (b) Errado, claro que pode ser realizado com o sistema em operação; (c) Errado, pode ser aplicado em programas que utilizem quaisquer linguagens de programação; (d) Errado, esse seria um teste caixa-branca; (e) Correto, ele realmente visa assegurar que o sistema computacional pode operar sob a carga de operação especificada (Letra E).

front: (MEC – 2015) A realização de testes de desempenho deve ser realizada o quanto antes, ainda durante a etapa de arquitetura e implementação da solução. Para este fim, deve- se adotar estratégia que identifique as partes de uma funcionalidade que estejam demorando mais tempo para serem executadas, no nível de teste de componente ou no nível de integração de componente.
response: Correto
comment: testes de desempenho podem ocorrer em todas as etapas do processo de testes e deve começar o quando antes. Os resultados desses testes permitem a realização de análises que podem ajudar a estimar a configuração do hardware necessária para suportar o software em questão (Correto).
Other fields (not shown on cards):
back: Correto - testes de desempenho podem ocorrer em todas as etapas do processo de testes e deve começar o quando antes. Os resultados desses testes permitem a realização de análises que podem ajudar a estimar a configuração do hardware necessária para suportar o software em questão (Correto).

front: (MEC – 2015) Um teste de desempenho deve ser realizado para mensurar se a infraestrutura tecnológica de produção é suficiente para suportar a quantidade de acessos simultâneos à aplicação web. Uma forma de realizar essa verificação é utilizar ferramenta com suporte à medição de teste de cobertura.
response: Correto
comment: ele realmente é realizado para mensurar se a infraestrutura tecnológica em produção (isto é, aquela que será utilizada para executar o software) é capaz de suportar a quantidade de acessos simultâneos. De fato, uma forma de realizar essa verificação é por meio de ferramentas de teste de cobertura, que conseguem analisar a abrangência do teste realizado. Se você testa de forma mais abrangente possível, você descobre quanto o software pode suporte (Correto).
Other fields (not shown on cards):
back: Correto - ele realmente é realizado para mensurar se a infraestrutura tecnológica em produção (isto é, aquela que será utilizada para executar o software) é capaz de suportar a quantidade de acessos simultâneos. De fato, uma forma de realizar essa verificação é por meio de ferramentas de teste de cobertura, que conseguem analisar a abrangência do teste realizado. Se você testa de forma mais abrangente possível, você descobre quanto o software pode suporte (Correto).

front: (TCE/PR – 2011) Segundo Sommerville, após um sistema ser completamente integrado, é possível testar propriedades como a de desempenho do sistema. Neste contexto, considere:
I. Testes de desempenho devem ser produzidos de forma a garantir que o sistema possa processar a sua carga prevista, sendo que tais testes geralmente são planejados para que a carga seja continuamente aumentada até que o sistema apresente desempenho fora do aceitável.
II. Os testes de desempenho devem determinar se um sistema corresponde às suas exigências, sendo que a descoberta de defeitos ou problemas no sistema não é enfoque desta etapa.
III. Para determinar se o desempenho está sendo atingido, pode ser necessário a construção de um perfil operacional, que é a listagem de todo o grupo de operadores/usuários que farão uso deste sistema.
Está correto o que se afirma em:
a) I, apenas.
b) I, II, III.
c) III, apenas.
d) I e II, apenas.
e) II e III, apenas.
response: Alternativa A
comment: (I) Correto. Testes de Desempenho devem – de fato - ser projetados para assegurar que o sistema pode operar na carga necessária, envolvendo, geralmente, o planejamento de uma série de testes em que a carga é constantemente aumentada até que o desempenho se torne inaceitável; (II) Errado. Um dos objetivos primários do teste de desempenho é demonstrar que o sistema atende aos requisitos e descobrir problemas e defeitos no sistema; (III) Errado. Na verdade, um perfil operacional é um conjunto de testes que refletem uma combinação real de trabalho a que o sistema será submetido (Letra A).
Other fields (not shown on cards):
back: Alternativa A - (I) Correto. Testes de Desempenho devem – de fato - ser projetados para assegurar que o sistema pode operar na carga necessária, envolvendo, geralmente, o planejamento de uma série de testes em que a carga é constantemente aumentada até que o desempenho se torne inaceitável; (II) Errado. Um dos objetivos primários do teste de desempenho é demonstrar que o sistema atende aos requisitos e descobrir problemas e defeitos no sistema; (III) Errado. Na verdade, um perfil operacional é um conjunto de testes que refletem uma combinação real de trabalho a que o sistema será submetido (Letra A).

front: (IF/SC – 2014) O teste de stress tem por objetivo avaliar como o sistema responde em condições anormais. Pode abranger cargas de trabalho extremas, memória insuficiente, hardware e serviços indisponíveis ou recursos compartilhados limitados.
response: Correto
comment: esse tipo de teste realmente busca avaliar a resposta do sistema em condições anormais de utilização pelo usuário (Correto).
Other fields (not shown on cards):
back: Correto - esse tipo de teste realmente busca avaliar a resposta do sistema em condições anormais de utilização pelo usuário (Correto).

front: (MEC – 2015) Após um sistema ter sido completamente integrado, é possível testá-lo em relação ao desempenho e à confiabilidade. O teste de desempenho significa estressar o sistema por meio de demandas fora dos limites do projeto de software.
response: Correto
comment: a questão trata do teste de estresse, que é um tipo de teste de desempenho (Correto)
Other fields (not shown on cards):
back: Correto - a questão trata do teste de estresse, que é um tipo de teste de desempenho (Correto)

front: (COPASA – 2014) Sobre os testes de estresse, assinale a alternativa incorreta.
a) Ocorrem quando módulos ou subsistemas são integrados para criar sistemas maiores.
b) Testa o comportamento de falha do sistema.
c) Causa estresse no sistema e pode acarretar a detecção de defeitos que, normalmente, não se manifestariam.
d) São relevantes para sistemas distribuídos, com base em uma rede de computadores.
response: Alternativa A
comment: (a) Errado, a questão trata de testes de integração; (b) Correto, testes de estresse realmente testam o comportamento de falha do sistema; (c) Correto, testes de estresse causam estresse no sistema e podem acarretar a detecção de defeitos que normalmente não se manifestariam; (d) Correto, isso permite detectar gargalos e anomalias (Letra A).
Other fields (not shown on cards):
back: Alternativa A - (a) Errado, a questão trata de testes de integração; (b) Correto, testes de estresse realmente testam o comportamento de falha do sistema; (c) Correto, testes de estresse causam estresse no sistema e podem acarretar a detecção de defeitos que normalmente não se manifestariam; (d) Correto, isso permite detectar gargalos e anomalias (Letra A).

front: (MPE/SE – 2009) A execução de um sistema com o objetivo de encontrar falhas sob condições que demandam recursos em quantidade, frequência ou volume anormais é definida como:
a) payload.
b) teste de estresse.
c) teste de desempenho.
d) latência da falha.
e) workload.
response: Alternativa B
comment: a questão nos remete claramente a teste de estresse (Letra B).
Other fields (not shown on cards):
back: Alternativa B - a questão nos remete claramente a teste de estresse (Letra B).

front: (INFRAERO – 2011) Executa um sistema de forma a demandar recursos em volume ou frequência acima do normal. Trata-se de:
a) validação de unidade de implementação.
b) teste beta.
c) teste de estresse.
d) validação de integração.
e) teste de desempenho.
response: Alternativa C
comment: o teste que executa o sistema de forma a demandar recursos em volume ou frequência acima do normal é o teste de estresse (Letra C).
Other fields (not shown on cards):
back: Alternativa C - o teste que executa o sistema de forma a demandar recursos em volume ou frequência acima do normal é o teste de estresse (Letra C).

front: (BRDE – 2015) Qual tipo de teste é usado para testar especificamente o comportamento de um sistema sob demanda de recursos em quantidade, frequência ou volume anormais?
a) Teste de Recuperação.
b) Teste de Segurança.
c) Teste de Fluxo de Dados.
d) Teste de Integração.
e) Teste de Estresse.
response: Alternativa E
comment: o teste utilizado para testar especificamente o comportamento de um sistema sob demanda de recursos em quantidade, frequência ou volume anormais é o teste de estresse (Letra E).
Other fields (not shown on cards):
back: Alternativa E - o teste utilizado para testar especificamente o comportamento de um sistema sob demanda de recursos em quantidade, frequência ou volume anormais é o teste de estresse (Letra E).

front: (IF/SE – 2016) O teste de estresse deve ser feito com o objetivo de avaliar os efeitos da submissão do sistema a situações com alta demanda por recursos.
response: Correto
comment: trata-se do teste de estresse (Correto)
Other fields (not shown on cards):
back: Correto - trata-se do teste de estresse (Correto)

front: (TRT/ES – 2013) O teste de carga, que verifica o funcionamento do software, utiliza uma grande quantidade de usuários simultaneamente.
response: Errado
comment: o teste de carga verifica o funcionamento do software utilizando a quantidade de usuários acordados ou especificados – esse valor não é necessariamente grande (Errado).
Other fields (not shown on cards):
back: Errado - o teste de carga verifica o funcionamento do software utilizando a quantidade de usuários acordados ou especificados – esse valor não é necessariamente grande (Errado).

front: (ANTAQ – 2014) A realização de testes de carga é importante para os sistemas distribuídos, pois permite a identificação do ponto de degradação desses sistemas, o que possibilita a criação de controles de rejeição de operações a partir desse ponto.
response: Errado
comment: quem possibilita identificar o ponto de degradação ou crash do sistema é teste de estresse (Errado).
Other fields (not shown on cards):
back: Errado - quem possibilita identificar o ponto de degradação ou crash do sistema é teste de estresse (Errado).

front: (TCE/SC – 2016) Para se assegurar que o sistema opere com a carga necessária, são realizados testes de desempenho em que se aumenta progressivamente a carga até que se possa definir se o desempenho do sistema está aceitável.
response: Correto
comment: essa é uma questão polêmica porque aumentar progressivamente a carga até que se possa definir se o desempenho do sistema está aceitável é a definição de teste de carga, no entanto o teste de carga é um tipo de teste de desempenho – logo, questão perfeita (Correto)
Other fields (not shown on cards):
back: Correto - essa é uma questão polêmica porque aumentar progressivamente a carga até que se possa definir se o desempenho do sistema está aceitável é a definição de teste de carga, no entanto o teste de carga é um tipo de teste de desempenho – logo, questão perfeita (Correto)

front: (MEC – 2011) Os testes de usabilidade avaliam a facilidade de uso do software testado e são bastante utilizados em aplicações web.
response: Correto
comment: a questão está impecável – eles realmente avaliam a facilidade de uso do software e são muito aplicados em aplicações web (Correto).
Other fields (not shown on cards):
back: Correto - a questão está impecável – eles realmente avaliam a facilidade de uso do software e são muito aplicados em aplicações web (Correto).

front: (TCE/PA – 2016) É desnecessária a elaboração de protótipos para desenvolvimento de interface web.
response: Errado
comment: é fundamental a elaboração de protótipos (Errado).
Other fields (not shown on cards):
back: Errado - é fundamental a elaboração de protótipos (Errado).

front: (MPE/PB – 2015) Considere os seguintes testes de software:
I. Avaliar o desempenho da interação homem-computador.
II. Obter indícios do nível de satisfação do usuário.
III. Avaliar a integridade dos dados registrados no sistema.
Pode ser considerado teste de usabilidade o que consta APENAS em:
a) I.
b) II.
c) III.
d) I e II.
e) II e III.
response: Alternativa D
comment: (I) Correto, ele de fato avalia o desempenho da interação homem-computador; (II) Correto, ele realmente é capaz de obter indícios do nível de satisfação do usuário; (III) Errado, ele não tem nenhuma intenção de avaliar a integridade dos dados registrados no sistema (Letra D).
Other fields (not shown on cards):
back: Alternativa D - (I) Correto, ele de fato avalia o desempenho da interação homem-computador; (II) Correto, ele realmente é capaz de obter indícios do nível de satisfação do usuário; (III) Errado, ele não tem nenhuma intenção de avaliar a integridade dos dados registrados no sistema (Letra D).

front: (TJ/PI – 2015) Um sistema matemático, já em utilização, vem sofrendo diversas manutenções evolutivas. Após uma das novas funcionalidades ter sido implementada, a equipe responsável percebeu que algumas funcionalidades antigas começaram a apresentar falhas em seus resultados. Os membros da equipe, ainda inexperientes, definiram algumas medidas para verificar a possível causa do problema. A medida inicial mais adequada a ser adotada é:
a) novas entrevistas com o cliente;
b) reavaliação do escopo;
c) novos testes unitários;
d) testes de regressão;
e) revisão da modelagem.
response: Alternativa D
comment: após uma das novas funcionalidades ter sido implementada, a equipe responsável percebeu que algumas funcionalidades antigas começaram a apresentar falhas em seus resultados. Logo, a medida inicial mais adequada a ser adotada é o teste de regressão (Letra D).
Other fields (not shown on cards):
back: Alternativa D - após uma das novas funcionalidades ter sido implementada, a equipe responsável percebeu que algumas funcionalidades antigas começaram a apresentar falhas em seus resultados. Logo, a medida inicial mais adequada a ser adotada é o teste de regressão (Letra D).

front: (FUNPRESP/JUD – 2016) O teste de regressão visa garantir a integridade de um software já testado que tenha recebido uma nova implementação.
response: Correto
comment: testes de regressão são desenvolvidos de forma incremental para verificar se as mudanças no programa não introduziram novos bugs (Correto).
Other fields (not shown on cards):
back: Correto - testes de regressão são desenvolvidos de forma incremental para verificar se as mudanças no programa não introduziram novos bugs (Correto).

front: (TRE/BA – 2010) Falha é o resultado de um ou mais defeitos em algum aspecto do sistema. No teste de regressão, caso um novo componente ou as suas alterações, quando acrescentados aos componentes restantes do sistema, resultem em novos defeitos em componentes inalterados, então considera-se que o sistema regrediu.
response: Correto
comment: perfeito, perfeito, perfeito! Galera, quando um sistema não passa nos testes de regressão, nós dizemos que o sistema regrediu. Por que? Porque antes ele funcionava corretamente e, após a inserção de novas funcionalidades, ele parou de funcionar. Esse item é coisa linda! (Correto
Other fields (not shown on cards):
back: Correto - perfeito, perfeito, perfeito! Galera, quando um sistema não passa nos testes de regressão, nós dizemos que o sistema regrediu. Por que? Porque antes ele funcionava corretamente e, após a inserção de novas funcionalidades, ele parou de funcionar. Esse item é coisa linda! (Correto

front: (MPE/SC – 2014) Nos termos de Engenharia de Software, assinale a alternativa que contém o tipo de teste de software correspondente àquele realizado imediatamente após a conclusão da fase de desenvolvimento, e que visa testar se o software roda e provê suas funcionalidades e características básicas, de forma a estar habilitado para receber testes mais detalhados, ou se ele possui algum problema estrutural básico (ex. o software não roda) que deve ser corrigido antes de realizar outros tipos de testes:
a) Teste de carga (stress testing)
b) Teste de fumaça (smoke testing)
c) Teste do sistema (system testing)
d) Teste de aceitação (acceptance testing)
e) Teste de desempenho (performance testing)
response: Alternativa B
comment: trata-se do teste de fumaça. Há apenas uma observação – ele não ocorre apenas após a fase de desenvolvimento, ele ocorre sempre que há uma nova integração, isto é, uma nova funcionalidade (Letra B).
Other fields (not shown on cards):
back: Alternativa B - trata-se do teste de fumaça. Há apenas uma observação – ele não ocorre apenas após a fase de desenvolvimento, ele ocorre sempre que há uma nova integração, isto é, uma nova funcionalidade (Letra B).

front: (ABIN – 2010) Para a verificação de resultados de um protótipo de sistema, podem-se utilizar testes back-to-back, nos quais os mesmos casos de teste são submetidos ao protótipo e ao sistema em teste a fim de se produzir um relatório de diferenças.
response: Correto
comment: realmente é possível utilizar o teste back-to-back (ou comparação) para os mesmos casos de teste de entrada em sistemas diferentes a fim de gerar um relatório de diferenças (Correto).
Other fields (not shown on cards):
back: Correto - realmente é possível utilizar o teste back-to-back (ou comparação) para os mesmos casos de teste de entrada em sistemas diferentes a fim de gerar um relatório de diferenças (Correto).

front: (TCE/RO – 2007) O teste alfa (alpha test) é conduzido pelo:
a) cliente, no seu próprio ambiente.
b) cliente, no ambiente do desenvolvedor.
c) analista de teste, no ambiente do desenvolvedor.
d) analista de teste, no seu próprio ambiente.
e) desenvolvedor, no seu próprio ambiente.
response: Alternativa B
comment: teste alfa é conduzido pelo cliente no ambiente do desenvolvedor (Letra B).
Other fields (not shown on cards):
back: Alternativa B - teste alfa é conduzido pelo cliente no ambiente do desenvolvedor (Letra B).

front: (COPASA – 2018) Teste realizado na instalação do desenvolvedor com os usuários finais, em um ambiente controlado, para identificar erros e problemas de uso durante a operação do sistema pelos usuários é denominado:
a) Teste Alfa.
b) Teste Beta.
c) Teste de Regressão.
d) Teste Fumaça.
response: Alternativa A
comment: realizado na instalação do desenvolvedor com os usuários finais em um ambiente controlado é o teste alfa (Letra A).
Other fields (not shown on cards):
back: Alternativa A - realizado na instalação do desenvolvedor com os usuários finais em um ambiente controlado é o teste alfa (Letra A).

front: (COPASA – 2018) Teste realizado em ambiente de produção por um grupo de usuários finais para identificar problemas e realizar as devidas correções antes de liberar o software para toda a base de clientes:
a) Teste Alfa.
b) Teste Beta.
c) Teste de Regressão.
d) Teste Fumaça.
response: Alternativa B
comment: realizado no ambiente de produção (ambiente operacional) é o teste beta (Letra B).
Other fields (not shown on cards):
back: Alternativa B - realizado no ambiente de produção (ambiente operacional) é o teste beta (Letra B).

front: (DATAPREV – 2011) Com relação aos testes de software, convenciona-se dizer que:
a) Teste Alfa é realizado com o software em fase de codificação e o Teste Beta é feito com o software já pronto.
b) Teste Alfa é feito em ambiente controlado e o Teste Beta, no ambiente do usuário.
c) Teste Alfa é feito pelos usuários e o Teste Beta, pelos desenvolvedores, simultaneamente.
d) Teste Alfa é feito na fase de criação e o Teste Beta, na fase de produção
e) Teste Alfa é feito sem os dados e o Teste Beta é feito com dados fictícios.
response: Alternativa B
comment: testes alfa são realizados em ambiente controlado e testes beta são realizados no ambiente do usuário (Letra B)
Other fields (not shown on cards):
back: Alternativa B - testes alfa são realizados em ambiente controlado e testes beta são realizados no ambiente do usuário (Letra B)

front: (EPE – 2007) Devido ao aumento da demanda por aplicações que funcionem 24 horas por dia na Internet, um software deve ser capaz de manter-se em operação após uma determinada falha. A estratégia de teste que melhor garante essa característica é o(a):
a) teste de estresse.
b) teste de recuperação.
c) teste unitário.
d) debugging.
e) simulação combinatória.
response: Alternativa B
comment: o termo estratégia de teste não é o mais adequado; de todo modo, o teste que melhor garante a característica de ser capaz de manter um software em operação após uma determinada falha é o teste de recuperação (Letra B).
Other fields (not shown on cards):
back: Alternativa B - o termo estratégia de teste não é o mais adequado; de todo modo, o teste que melhor garante a característica de ser capaz de manter um software em operação após uma determinada falha é o teste de recuperação (Letra B).

front: MPE/ES – 2013) Há uma técnica de teste de software chamada de teste de recuperação, que tem como premissa:
a) fazer com que o software falhe e verificar se ocorre, corretamente, sua recuperação.
b) rodar um teste de grande tempo de duração, esperando que não haja falhas registradas no software.
c) verificar se apenas usuários autorizados conseguem acessar o sistema.
d) verificar se o software atende adequadamente aos limites máximos de utilização estabelecidos.
e) verificar se são atendidos os tempos máximos e médios especificados para a realização das tarefas.
response: Alternativa A
comment: mais uma vez, o termo não foi adequado; de todo modo, vamos avaliar: (a) Correto, essa é a premissa fundamental do teste de recuperação; (b) Errado, está mais próximo a um teste operacional; (c) Errado, isso não tem nenhuma relação com teste de recuperação; (d) Errado, está mais próximo a um teste de carga; (e) Errado, está mais próximo a um teste de carga (Letra A).
Other fields (not shown on cards):
back: Alternativa A - mais uma vez, o termo não foi adequado; de todo modo, vamos avaliar: (a) Correto, essa é a premissa fundamental do teste de recuperação; (b) Errado, está mais próximo a um teste operacional; (c) Errado, isso não tem nenhuma relação com teste de recuperação; (d) Errado, está mais próximo a um teste de carga; (e) Errado, está mais próximo a um teste de carga (Letra A).

front: (COPASA – 2018) O “Teste de Recuperação” força o software a falhar de diversos modos e verifica se a recuperação é adequadamente realizada.
response: Correto
comment: a questão está impecável (Correto)
Other fields (not shown on cards):
back: Correto - a questão está impecável (Correto)

front: (PETROBRÁS – 2013) O teste de recuperação é um teste de sistema que força o software a falhar de diversos modos e verifica se a recuperação é adequadamente realizada, seja ela feita de forma automática (realizada pelo próprio sistema) ou requerendo intervenção humana.
response: Correto
comment: a questão está impecável – ademais, realmente pode ocorrer de forma automática ou manual (Correto).
Other fields (not shown on cards):
back: Correto - a questão está impecável – ademais, realmente pode ocorrer de forma automática ou manual (Correto).

front: (MEC – 2011) O teste de compatibilidade serve para verificar se um software pode ser executado no sistema operacional Solaris.
response: Correto
comment: eles realmente servem para testar um software em ambientes diferentes de hardware, software, sistema operacional, redes, entre outros (Correto).
Other fields (not shown on cards):
back: Correto - eles realmente servem para testar um software em ambientes diferentes de hardware, software, sistema operacional, redes, entre outros (Correto).

front: (FUB – 2018) Para que um teste de invasão leve informações úteis à segurança de uma aplicação web, é importante que tal aplicação esteja em um estágio avançado no seu ciclo de desenvolvimento.
response: Correto
comment: aplicações em estágios iniciais de desenvolvimento geralmente sequer possuem funcionalidades implementadas, logo não possuem informações úteis e não são de interesse de testes de invasão (Correto).
Other fields (not shown on cards):
back: Correto - aplicações em estágios iniciais de desenvolvimento geralmente sequer possuem funcionalidades implementadas, logo não possuem informações úteis e não são de interesse de testes de invasão (Correto).

front: (COPASA – 2018) O “Teste de Segurança” verifica se os mecanismos de proteção incorporados a um sistema vão de fato protegê-lo de invasão imprópria.
response: Correto
comment: a questão está perfeita – essa é a função de um teste de segurança (Correto).
Other fields (not shown on cards):
back: Correto - a questão está perfeita – essa é a função de um teste de segurança (Correto).

front: (PROF. DIEGO / INÉDITA – 2024) É recomendável executar os testes de vulnerabilidade em ambientes de produção a fim de garantir resultados mais precisos e realistas.
response: Errado
comment: embora testar em ambientes de produção possa fornecer dados realistas, isso pode apresentar riscos significativos de interrupção dos serviços e outros impactos operacionais. Normalmente, os testes são realizados em ambientes de teste ou desenvolvimento para evitar tais riscos (Errado).
Other fields (not shown on cards):
back: Errado - embora testar em ambientes de produção possa fornecer dados realistas, isso pode apresentar riscos significativos de interrupção dos serviços e outros impactos operacionais. Normalmente, os testes são realizados em ambientes de teste ou desenvolvimento para evitar tais riscos (Errado).

front: (PROF. DIEGO / INÉDITA – 2024) Testes de Vulnerabilidade, ao identificarem falhas de segurança, fornecem soluções específicas para corrigir cada vulnerabilidade encontrada.
response: Correto
comment: parte do processo de teste de vulnerabilidade inclui não apenas a identificação de vulnerabilidades, mas também a recomendação de medidas corretivas. Essas recomendações são geralmente detalhadas e específicas, orientando os responsáveis pela segurança da informação sobre como remediar as falhas identificadas (Correto).
Other fields (not shown on cards):
back: Correto - parte do processo de teste de vulnerabilidade inclui não apenas a identificação de vulnerabilidades, mas também a recomendação de medidas corretivas. Essas recomendações são geralmente detalhadas e específicas, orientando os responsáveis pela segurança da informação sobre como remediar as falhas identificadas (Correto).

front: (CESPE / TCE-RJ – 2022) Quando aplicados os princípios FIRST em testes de unidade, o S representa a autovalidação, que gera um resultado a ser interpretado pelo responsável.
response: Errado
comment: a afirmação erra ao associar o "S" de Self-Validating (Autovalidação) a algo que necessita interpretação externa; na verdade, testes autovalidáveis devem produzir um resultado claro (aprovado ou reprovado) sem necessidade de interpretação adicional (Errado).
Other fields (not shown on cards):
back: Errado - a afirmação erra ao associar o "S" de Self-Validating (Autovalidação) a algo que necessita interpretação externa; na verdade, testes autovalidáveis devem produzir um resultado claro (aprovado ou reprovado) sem necessidade de interpretação adicional (Errado).

front: (FCC / TRE-AP – 2015) O TDD − Test Driven Development (Desenvolvimento orientado a teste):
a) é parte das metodologias ágeis UP − Unified Process e XP − Extreme Programming, tendo sido criado para ser usado em metodologias que respeitam os 4 princípios do Manifesto Ágil.
b) transforma o desenvolvimento, pois deve-se primeiro implementar o sistema antes de escrever os testes. Os testes são utilizados para facilitar no entendimento do projeto e para clarear o que se deseja em relação ao código.
c) baseia-se em um ciclo simples: escreve-se um código -> cria-se um teste para passar no código -> refatora-se.
d) propõe a criação de testes que validem o código como um todo para reduzir o tempo de desenvolvimento.
e) beneficia-se de testes que seguem o modelo FIRST: F (Fast) I (Isolated) R (Repeatable) S (Self-verifying) T (Timely).
response: Alternativa E
comment: (a) Errado. O TDD é uma prática comum em metodologias ágeis como o XP (Extreme Programming), baseando-se nos princípios do Manifesto Ágil, que promove desenvolvimento iterativo, colaboração, e resposta a mudanças. No entanto, UP (Unified Process) não é uma metodologia ágil – ele é baseado no RUP (Rational Unified Process); (b) Errado. O TDD, ao contrário, enfatiza a escrita dos testes antes do desenvolvimento do sistema propriamente dito. Nesse sentido, os testes orientam o desenvolvimento do código, assegurando que o código atenda aos requisitos definidos desde o início; (c) Errado. O ciclo do TDD é mais específico e estruturado do que o descrito: primeiro escreve-se um teste que falha, depois implementa-se o código necessário para passar no teste e, por fim, refatora-se o código para melhorar a qualidade sem alterar seu comportamento; (d) Errado. A ideia do TDD não é validar o código como um todo de imediato, mas sim promover um desenvolvimento incremental e contínuo por meio de testes pequenos e específicos que validam partes do código à medida que são desenvolvidas; (e) Correto. Os testes no TDD são benéficos quando seguem o modelo FIRST, que destaca características importantes que os testes devem ter para serem eficazes no desenvolvimento orientado a testes, como serem rápidos, isolados, repetíveis, autovalidáveis e oportunos (Letra E)
Other fields (not shown on cards):
back: Alternativa E - (a) Errado. O TDD é uma prática comum em metodologias ágeis como o XP (Extreme Programming), baseando-se nos princípios do Manifesto Ágil, que promove desenvolvimento iterativo, colaboração, e resposta a mudanças. No entanto, UP (Unified Process) não é uma metodologia ágil – ele é baseado no RUP (Rational Unified Process); (b) Errado. O TDD, ao contrário, enfatiza a escrita dos testes antes do desenvolvimento do sistema propriamente dito. Nesse sentido, os testes orientam o desenvolvimento do código, assegurando que o código atenda aos requisitos definidos desde o início; (c) Errado. O ciclo do TDD é mais específico e estruturado do que o descrito: primeiro escreve-se um teste que falha, depois implementa-se o código necessário para passar no teste e, por fim, refatora-se o código para melhorar a qualidade sem alterar seu comportamento; (d) Errado. A ideia do TDD não é validar o código como um todo de imediato, mas sim promover um desenvolvimento incremental e contínuo por meio de testes pequenos e específicos que validam partes do código à medida que são desenvolvidas; (e) Correto. Os testes no TDD são benéficos quando seguem o modelo FIRST, que destaca características importantes que os testes devem ter para serem eficazes no desenvolvimento orientado a testes, como serem rápidos, isolados, repetíveis, autovalidáveis e oportunos (Letra E)

front: (CESPE / CNPq – 2024) Os testes de carga e os testes de esforço são testes de desempenho que exigem instrumentação de hardware e software, uma vez que frequentemente é necessário medir a utilização dos recursos de forma precisa.
response: Correto
comment: Os testes de carga e os testes de esforço são tipos de testes de desempenho que requerem instrumentação de hardware e software para medir com precisão a utilização de recursos como CPU, memória, rede e disco. Esses testes ajudam a identificar gargalos e a capacidade máxima do sistema sob diferentes condições de carga.
Other fields (not shown on cards):
back: Correto - Os testes de carga e os testes de esforço são tipos de testes de desempenho que requerem instrumentação de hardware e software para medir com precisão a utilização de recursos como CPU, memória, rede e disco. Esses testes ajudam a identificar gargalos e a capacidade máxima do sistema sob diferentes condições de carga.

front: (CESPE / CAU-BR – 2024) Considerada uma técnica sistemática para construir a arquitetura de software concomitantemente à realização de testes para descobrir erros associados às interfaces, o teste de integração realiza testes a partir de componentes testados em unidade.
response: Correto
comment: O teste de integração é uma técnica sistemática usada para verificar a interação entre diferentes componentes ou unidades de software. Após a realização de testes de unidade em cada componente individualmente, o teste de integração combina esses componentes e testa suas interfaces para identificar erros na comunicação e interação entre eles.
Other fields (not shown on cards):
back: Correto - O teste de integração é uma técnica sistemática usada para verificar a interação entre diferentes componentes ou unidades de software. Após a realização de testes de unidade em cada componente individualmente, o teste de integração combina esses componentes e testa suas interfaces para identificar erros na comunicação e interação entre eles.

front: (CESPE / CAU-BR – 2024) Considerando que o teste funcional objetiva determinar se um recurso funciona corretamente sem problemas, é possível automatizar esse tipo de teste mesmo que o sistema seja web, em que é possível simular os retornos esperados.
response: Correto
comment: Testes funcionais podem ser automatizados, inclusive em sistemas web. Ferramentas como Selenium, Cypress e QTP permitem simular interações do usuário e validar se o sistema funciona corretamente conforme especificado, verificando os retornos esperados de funcionalidades específicas.
Other fields (not shown on cards):
back: Correto - Testes funcionais podem ser automatizados, inclusive em sistemas web. Ferramentas como Selenium, Cypress e QTP permitem simular interações do usuário e validar se o sistema funciona corretamente conforme especificado, verificando os retornos esperados de funcionalidades específicas.

front: (CESPE / CAU-BR – 2024) Os testes de regressão são realizados por ocasião da ocorrência de mudanças no software.
response: Correto
comment: Os testes de regressão são realizados quando ocorrem mudanças no software para garantir que as alterações feitas não introduzam novos defeitos em partes previamente funcionais do sistema. Esses testes reexecutam os casos de teste existentes para verificar se o software continua a operar corretamente após as modificações, como correções de bugs, adição de novas funcionalidades ou melhorias.
Other fields (not shown on cards):
back: Correto - Os testes de regressão são realizados quando ocorrem mudanças no software para garantir que as alterações feitas não introduzam novos defeitos em partes previamente funcionais do sistema. Esses testes reexecutam os casos de teste existentes para verificar se o software continua a operar corretamente após as modificações, como correções de bugs, adição de novas funcionalidades ou melhorias.

front: (CESPE / TST – 2024) Assinale a opção em que é apresentada uma técnica de desenvolvimento de software orientada a testes que é voltada para o atendimento dos requisitos do sistema com base no negócio, que utiliza exemplos e dublês de teste e que descreve funcionalidades por meio da sintaxe dado que, quando e então:
a) teste unitário de software
b) desenvolvimento orientado por comportamento (BDD)
c) desenvolvimento guiado por testes (TDD)
d) desenvolvimento guiado por testes de aceitação (ATDD)
e) testes de aceitação de usuário (UAT)
response: Letra B
comment: (a) Errado. Teste unitário de software é uma técnica que testa unidades individuais de código, como funções ou métodos, de forma isolada; (b) Correto. Desenvolvimento orientado por comportamento (BDD) é uma técnica que se concentra no comportamento do sistema de acordo com os requisitos de negócios, utilizando exemplos e dublês de teste, e descrevendo funcionalidades com a sintaxe dado que, quando, e então; (c) Errado. Desenvolvimento guiado por testes (TDD) é uma técnica que envolve escrever testes antes de implementar o código, mas não necessariamente usa a sintaxe dado que, quando, e então; (d) Errado. Desenvolvimento guiado por testes de aceitação (ATDD) é uma técnica onde os testes de aceitação são escritos antes do desenvolvimento, mas não foca especificamente na sintaxe dado que, quando, e então; (e) Errado. Testes de aceitação de usuário (UAT) são realizados pelos usuários finais para validar se o sistema atende aos requisitos de negócios, mas não utilizam a técnica e sintaxe específica do BDD.
Other fields (not shown on cards):
back: Letra B - (a) Errado. Teste unitário de software é uma técnica que testa unidades individuais de código, como funções ou métodos, de forma isolada; (b) Correto. Desenvolvimento orientado por comportamento (BDD) é uma técnica que se concentra no comportamento do sistema de acordo com os requisitos de negócios, utilizando exemplos e dublês de teste, e descrevendo funcionalidades com a sintaxe dado que, quando, e então; (c) Errado. Desenvolvimento guiado por testes (TDD) é uma técnica que envolve escrever testes antes de implementar o código, mas não necessariamente usa a sintaxe dado que, quando, e então; (d) Errado. Desenvolvimento guiado por testes de aceitação (ATDD) é uma técnica onde os testes de aceitação são escritos antes do desenvolvimento, mas não foca especificamente na sintaxe dado que, quando, e então; (e) Errado. Testes de aceitação de usuário (UAT) são realizados pelos usuários finais para validar se o sistema atende aos requisitos de negócios, mas não utilizam a técnica e sintaxe específica do BDD.

front: (CESPE / TST – 2024) O projeto de software é a primeira atividade técnica voltada à construção de software e deve ser iniciada logo após:
a) o teste de software.
b) o projeto de dados.
c) o projeto arquitetural.
d) a análise e a especificação de requisitos.
e) a codificação.
response: Letra D
comment: (a) Errado. O teste de software ocorre após a codificação e não precede o projeto de software; (b) Errado. O projeto de dados é uma etapa que pode estar incluída no projeto de software, mas não precede a análise e especificação de requisitos; (c) Errado. O projeto arquitetural é uma parte do projeto de software, não uma atividade que ocorre antes dele; (d) Correto. A análise e a especificação de requisitos são etapas que identificam e documentam o que o sistema deve fazer e servem de base para o projeto de software; (e) Errado. A codificação é a fase de implementação que ocorre após o projeto de software.
Other fields (not shown on cards):
back: Letra D - (a) Errado. O teste de software ocorre após a codificação e não precede o projeto de software; (b) Errado. O projeto de dados é uma etapa que pode estar incluída no projeto de software, mas não precede a análise e especificação de requisitos; (c) Errado. O projeto arquitetural é uma parte do projeto de software, não uma atividade que ocorre antes dele; (d) Correto. A análise e a especificação de requisitos são etapas que identificam e documentam o que o sistema deve fazer e servem de base para o projeto de software; (e) Errado. A codificação é a fase de implementação que ocorre após o projeto de software.

front: (CESPE / MPE-GO – 2024) Caso seja necessário verificar se o software desenvolvido está funcionando conforme o esperado e garantir que suas principais funções não apresentem grandes falhas, na execução rápida de seus principais recursos, indica-se a realização do teste fumaça.
response: Correto
comment: O teste de fumaça é uma abordagem rápida e inicial para verificar se o software desenvolvido está funcionando conforme o esperado nas suas principais funcionalidades. Esse tipo de teste visa garantir que as funções mais críticas não apresentem falhas significativas e que o sistema está estável o suficiente para que testes mais detalhados sejam realizados posteriormente. Ele serve como uma verificação preliminar para identificar problemas óbvios que podem impedir a execução completa de testes mais exaustivos.
Other fields (not shown on cards):
back: Correto - O teste de fumaça é uma abordagem rápida e inicial para verificar se o software desenvolvido está funcionando conforme o esperado nas suas principais funcionalidades. Esse tipo de teste visa garantir que as funções mais críticas não apresentem falhas significativas e que o sistema está estável o suficiente para que testes mais detalhados sejam realizados posteriormente. Ele serve como uma verificação preliminar para identificar problemas óbvios que podem impedir a execução completa de testes mais exaustivos.

front: (CESPE / LNA – 2024) Assinale a opção em que é corretamente apresentado o tipo de teste de software responsável por verificar se diferentes partes do sistema de software foram projetadas para interagir entre si e se fazem essa interação corretamente, avaliando, inclusive, como os dados são transferidos entre elas.
a) teste de desempenho
b) teste unitário
c) teste funcional
d) teste de integração
e) teste de aceitação
response: Letra D
comment: (a) Errado. Teste de desempenho verifica a performance do sistema, como tempo de resposta e utilização de recursos, não a interação entre partes do sistema; (b) Errado. Teste unitário verifica partes individuais do código (funções ou métodos) isoladamente, sem testar a interação entre diferentes componentes do sistema; (c) Errado. Teste funcional verifica se o sistema atende aos requisitos funcionais especificados, focando em saídas corretas para entradas dadas, não especificamente na interação entre componentes; (d) Correto. Teste de integração verifica se diferentes partes do sistema interagem corretamente entre si, incluindo a transferência de dados entre componentes; (e) Errado. Teste de aceitação verifica se o sistema atende aos requisitos e expectativas do usuário final, sem foco específico na interação entre componentes internos do sistema.
Other fields (not shown on cards):
back: Letra D - (a) Errado. Teste de desempenho verifica a performance do sistema, como tempo de resposta e utilização de recursos, não a interação entre partes do sistema; (b) Errado. Teste unitário verifica partes individuais do código (funções ou métodos) isoladamente, sem testar a interação entre diferentes componentes do sistema; (c) Errado. Teste funcional verifica se o sistema atende aos requisitos funcionais especificados, focando em saídas corretas para entradas dadas, não especificamente na interação entre componentes; (d) Correto. Teste de integração verifica se diferentes partes do sistema interagem corretamente entre si, incluindo a transferência de dados entre componentes; (e) Errado. Teste de aceitação verifica se o sistema atende aos requisitos e expectativas do usuário final, sem foco específico na interação entre componentes internos do sistema.

front: (CESPE / LNA – 2024) É uma característica-chave de um bom framework de automação de teste:
a) a falta de suporte a linguagens de programação populares.
b) a escalabilidade limitada.
c) a alta complexidade.
d) a baixa manutenibilidade.
e) a flexibilidade mínima.
response: Letra D
comment: (a) Errado. Um bom framework de automação de teste deve ter suporte a linguagens de programação populares para ser amplamente adotado e integrado com diferentes sistemas e equipes; (b) Errado. A escalabilidade limitada é uma característica negativa, pois um bom framework deve ser capaz de crescer conforme as necessidades do projeto aumentam; (c) Errado. A alta complexidade dificulta a implementação, manutenção e uso do framework. Um bom framework deve ser fácil de usar e configurar; (d) Correto. Um bom framework deve ser fácil de manter, logo deve exigir baixa manutenibilidade para atualizar e adaptar às mudanças; (e) Errado. A flexibilidade mínima é uma desvantagem, pois impede o framework de ser adaptado a diferentes necessidades e cenários de teste. Um bom framework deve ser flexível para suportar vários tipos de testes e configurações;
Other fields (not shown on cards):
back: Letra D - (a) Errado. Um bom framework de automação de teste deve ter suporte a linguagens de programação populares para ser amplamente adotado e integrado com diferentes sistemas e equipes; (b) Errado. A escalabilidade limitada é uma característica negativa, pois um bom framework deve ser capaz de crescer conforme as necessidades do projeto aumentam; (c) Errado. A alta complexidade dificulta a implementação, manutenção e uso do framework. Um bom framework deve ser fácil de usar e configurar; (d) Correto. Um bom framework deve ser fácil de manter, logo deve exigir baixa manutenibilidade para atualizar e adaptar às mudanças; (e) Errado. A flexibilidade mínima é uma desvantagem, pois impede o framework de ser adaptado a diferentes necessidades e cenários de teste. Um bom framework deve ser flexível para suportar vários tipos de testes e configurações;

front: (CESPE / LNA – 2024) Os frameworks de teste de software:
a) permitem o aumento da produtividade, apesar de não serem úteis para testar softwares em diferentes plataformas.
b) permitem o aumento da produtividade, ainda que não possam ser integrados a processos de integração contínua.
c) são usados exclusivamente para testes manuais.
d) são ferramentas para criar bugs no software.
e) fornecem estruturas e funcionalidades para automatizar os testes de software.
response: Letra E
comment: (a) Errado. Os frameworks de teste são úteis para testar softwares em diferentes plataformas, o que contradiz a afirmação; (b) Errado. Muitos frameworks de teste são integráveis a processos de integração contínua, aumentando a eficiência; (c) Errado. Frameworks de teste são usados principalmente para testes automatizados, não apenas para testes manuais; (d) Errado. O objetivo dos frameworks de teste é identificar bugs, não os criar; (e) Correto. Os frameworks de teste fornecem estruturas e funcionalidades para automatizar os testes de software, o que melhora a eficiência e a eficácia do processo de teste.
Other fields (not shown on cards):
back: Letra E - (a) Errado. Os frameworks de teste são úteis para testar softwares em diferentes plataformas, o que contradiz a afirmação; (b) Errado. Muitos frameworks de teste são integráveis a processos de integração contínua, aumentando a eficiência; (c) Errado. Frameworks de teste são usados principalmente para testes automatizados, não apenas para testes manuais; (d) Errado. O objetivo dos frameworks de teste é identificar bugs, não os criar; (e) Correto. Os frameworks de teste fornecem estruturas e funcionalidades para automatizar os testes de software, o que melhora a eficiência e a eficácia do processo de teste.

front: (CESPE / LNA – 2024) A abordagem que se concentra principalmente em examinar as estruturas internas ou os funcionamentos de uma aplicação de software é denominada teste de:
a) sistema.
b) caixa preta.
c) caixa branca.
d) aceitação.
e) caixa cinza.
response: Letra C
comment: (a) Errado. O teste de sistema verifica o sistema como um todo, focando em suas funcionalidades e comportamentos em relação aos requisitos, não nas estruturas internas; (b) Errado. O teste de caixa preta avalia a funcionalidade externa da aplicação, sem considerar suas estruturas internas ou o código; (c) Correto. O teste de caixa branca foca nas estruturas internas da aplicação, verificando o funcionamento do código e a lógica interna; (d) Errado. O teste de aceitação é realizado para validar o software em relação aos requisitos de negócios e necessidades do usuário, sem examinar as estruturas internas; (e) Errado. O teste de caixa cinza combina aspectos dos testes de caixa branca e preta, mas não se concentra exclusivamente nas estruturas internas.
Other fields (not shown on cards):
back: Letra C - (a) Errado. O teste de sistema verifica o sistema como um todo, focando em suas funcionalidades e comportamentos em relação aos requisitos, não nas estruturas internas; (b) Errado. O teste de caixa preta avalia a funcionalidade externa da aplicação, sem considerar suas estruturas internas ou o código; (c) Correto. O teste de caixa branca foca nas estruturas internas da aplicação, verificando o funcionamento do código e a lógica interna; (d) Errado. O teste de aceitação é realizado para validar o software em relação aos requisitos de negócios e necessidades do usuário, sem examinar as estruturas internas; (e) Errado. O teste de caixa cinza combina aspectos dos testes de caixa branca e preta, mas não se concentra exclusivamente nas estruturas internas.

front: (CESPE / MPO – 2024) Realiza-se o teste de estresse para confrontar os programas com situações anormais, de forma a exigir recursos em maior quantidade, frequência ou volume.
response: Correto
comment: O teste de estresse é uma técnica que avalia a estabilidade e a confiabilidade de um software submetendo-o a condições extremas e situações anormais. O objetivo é verificar como o sistema se comporta ao lidar com carga além de sua capacidade regular, demandando mais recursos, como CPU, memória e rede, para identificar pontos de falha e melhorar a resiliência do sistema.
Other fields (not shown on cards):
back: Correto - O teste de estresse é uma técnica que avalia a estabilidade e a confiabilidade de um software submetendo-o a condições extremas e situações anormais. O objetivo é verificar como o sistema se comporta ao lidar com carga além de sua capacidade regular, demandando mais recursos, como CPU, memória e rede, para identificar pontos de falha e melhorar a resiliência do sistema.

front: (CESPE / MPO – 2024) O teste automatizado pode conter recursos de auditoria eletrônica com avaliadores e geradores automáticos de testes.
response: Correto
comment: O teste automatizado frequentemente inclui ferramentas que permitem a criação, execução e avaliação de testes de forma automática. Esses testes podem incorporar recursos de auditoria eletrônica, como registradores de execução, geradores automáticos de casos de teste e avaliadores que verificam a conformidade do sistema com os requisitos especificados, facilitando a identificação de erros e o monitoramento contínuo da qualidade do software.
Other fields (not shown on cards):
back: Correto - O teste automatizado frequentemente inclui ferramentas que permitem a criação, execução e avaliação de testes de forma automática. Esses testes podem incorporar recursos de auditoria eletrônica, como registradores de execução, geradores automáticos de casos de teste e avaliadores que verificam a conformidade do sistema com os requisitos especificados, facilitando a identificação de erros e o monitoramento contínuo da qualidade do software.

front: (CESPE / INPI – 2024) Um teste de software de regressão estará corretamente projetado quando se considera, em cada uma das funções principais do software, apenas os testes que tratam de uma ou mais classes de erros.
response: Correto
comment: De acordo com Roger Pressman, o conjunto de testes de regressão deve ser projetado de forma a incluir somente aqueles testes que tratam de uma ou mais classes de erros em cada uma das funções principais do programa. Lembrando que existem três tipos diferentes de casos de testes: - Uma amostra representativa dos testes que usam todas as funções do software. - Testes adicionais que focalizam as funções de software que podem ser afetadas pela alteração. - Testes que focalizam os componentes do software que foram alterados.
Other fields (not shown on cards):
back: Correto - De acordo com Roger Pressman, o conjunto de testes de regressão deve ser projetado de forma a incluir somente aqueles testes que tratam de uma ou mais classes de erros em cada uma das funções principais do programa. Lembrando que existem três tipos diferentes de casos de testes: - Uma amostra representativa dos testes que usam todas as funções do software. - Testes adicionais que focalizam as funções de software que podem ser afetadas pela alteração. - Testes que focalizam os componentes do software que foram alterados.

front: (CESPE / CAU-BR – 2024) Os estágios das atividades de teste de software devem ser realizados na seguinte ordem: teste do sistema, teste de integração e teste de unidade.
response: Errado
comment: A ordem correta das atividades de teste de software é geralmente: teste de unidade, teste de integração e teste do sistema. - Teste de Unidade: primeiro, cada unidade ou componente individual do software é testado isoladamente para garantir que funcionam corretamente; - Teste de Integração: em seguida, as unidades são combinadas e testadas em conjunto para verificar se interagem corretamente; - Teste do Sistema: finalmente, o sistema completo é testado como um todo para assegurar que todos os componentes funcionam juntos como esperado e atendem aos requisitos especificados.
Other fields (not shown on cards):
back: Errado - A ordem correta das atividades de teste de software é geralmente: teste de unidade, teste de integração e teste do sistema. - Teste de Unidade: primeiro, cada unidade ou componente individual do software é testado isoladamente para garantir que funcionam corretamente; - Teste de Integração: em seguida, as unidades são combinadas e testadas em conjunto para verificar se interagem corretamente; - Teste do Sistema: finalmente, o sistema completo é testado como um todo para assegurar que todos os componentes funcionam juntos como esperado e atendem aos requisitos especificados.

front: (CESPE / SEFIN de Fortaleza-CE – 2023) Acerca dos testes de software e das ferramentas para automatização de testes, bem como do desenvolvimento orientado por comportamento, julgue o item que se segue. Na análise do valor limite, casos de teste podem ser derivados dos domínios de entrada e de saída.
response: Correto
comment: Na análise do valor limite (Boundary Value Analysis), casos de teste são criados com base nos limites das entradas e saídas, onde os erros são mais propensos a ocorrer. Essa técnica foca nos valores que estão exatamente nos limites inferior e superior, bem como nos valores imediatamente acima e abaixo desses limites, tanto para os domínios de entrada quanto para os de saída. Isso ajuda a identificar falhas em situações críticas, garantindo que o sistema lide corretamente com os valores extremos.
Other fields (not shown on cards):
back: Correto - Na análise do valor limite (Boundary Value Analysis), casos de teste são criados com base nos limites das entradas e saídas, onde os erros são mais propensos a ocorrer. Essa técnica foca nos valores que estão exatamente nos limites inferior e superior, bem como nos valores imediatamente acima e abaixo desses limites, tanto para os domínios de entrada quanto para os de saída. Isso ajuda a identificar falhas em situações críticas, garantindo que o sistema lide corretamente com os valores extremos.

front: (CESPE / SEFIN de Fortaleza-CE – 2023) Em um teste de integração, cada uma das unidades é testada separadamente para se observar se elas funcionam de forma adequada.
response: Errado
comment: No teste de integração, o foco não é testar as unidades individualmente, mas sim verificar a interação entre diferentes unidades ou módulos para garantir que funcionem corretamente quando combinados. O objetivo é identificar problemas na interface e na comunicação entre os componentes. O teste de unidades individualmente é chamado de teste unitário.
Other fields (not shown on cards):
back: Errado - No teste de integração, o foco não é testar as unidades individualmente, mas sim verificar a interação entre diferentes unidades ou módulos para garantir que funcionem corretamente quando combinados. O objetivo é identificar problemas na interface e na comunicação entre os componentes. O teste de unidades individualmente é chamado de teste unitário.

front: (CESPE / SEFIN de Fortaleza-CE – 2023) Em um teste funcional de software, os elementos de uma classe devem se comportar de maneira equivalente.
response: Correto
comment: Em um teste funcional, a técnica de partição de equivalência é utilizada para dividir os dados de entrada em classes de equivalência, onde todos os elementos dentro de uma classe devem se comportar de maneira semelhante ou equivalente. O objetivo é reduzir o número de casos de teste, garantindo que, ao testar um elemento de cada classe, o comportamento seja representativo de todos os elementos dessa classe. Se um elemento de uma classe passa no teste, espera-se que todos os outros elementos dessa mesma classe também passem.
Other fields (not shown on cards):
back: Correto - Em um teste funcional, a técnica de partição de equivalência é utilizada para dividir os dados de entrada em classes de equivalência, onde todos os elementos dentro de uma classe devem se comportar de maneira semelhante ou equivalente. O objetivo é reduzir o número de casos de teste, garantindo que, ao testar um elemento de cada classe, o comportamento seja representativo de todos os elementos dessa classe. Se um elemento de uma classe passa no teste, espera-se que todos os outros elementos dessa mesma classe também passem.

front: (CESPE / SEFIN de Fortaleza-CE – 2023) No particionamento de equivalências para a criação de casos de teste, devem ser consideradas apenas as partições válidas.
response: Errado
comment: No particionamento de equivalência, tanto as partições válidas quanto as partições inválidas devem ser consideradas. As partições válidas representam entradas que estão dentro dos limites normais de operação, enquanto as partições inválidas representam entradas fora desses limites. Testar ambas é fundamental para garantir que o sistema funcione corretamente com entradas válidas e lide adequadamente com entradas inválidas, como erros ou exceções.
Other fields (not shown on cards):
back: Errado - No particionamento de equivalência, tanto as partições válidas quanto as partições inválidas devem ser consideradas. As partições válidas representam entradas que estão dentro dos limites normais de operação, enquanto as partições inválidas representam entradas fora desses limites. Testar ambas é fundamental para garantir que o sistema funcione corretamente com entradas válidas e lide adequadamente com entradas inválidas, como erros ou exceções.

front: (CESPE / EMPREL – 2023) A escolha de casos de teste de unidade é fundamental para a redução dos custos dos testes e uma estratégia que pode ser adotada para a seleção de casos é a de teste de partição de equivalência. Nesse contexto, considere-se um programa que precisa aceitar as seguintes opções de tamanho de folha para impressão.
▪ 10,5 cm × 14,8 cm
▪ 14,8 cm × 21,0 cm
▪ 21,0 cm × 29,7 cm
▪ 29,7 cm × 42,0 cm
Nessa hipótese, para a aplicação correta da técnica de equivalência de partição com o número mínimo de casos de teste, é necessário realizar:
a) apenas um caso de teste, para verificar se o programa pode imprimir folhas em todos os tamanhos exigidos.
b) três casos de teste, para verificar se o programa pode imprimir folhas de 15 cm, 22 cm ou 30 cm.
c) quatro casos de teste, para verificar se o programa pode imprimir folhas em todos os tamanhos exigidos.
d) seis casos de teste, para verificar se o programa pode imprimir folhas em todos os tamanhos exigidos e para tamanhos menores que 10,5 cm e maiores de 29,7 cm.
e) cinco casos de teste, para verificar se o programa pode imprimir folhas em todos os tamanhos exigidos e para tamanhos maiores que 29,7 cm.
response: Letra D
comment: A técnica de particionamento de equivalência busca identificar classes válidas e inválidas, garantindo testes representativos com o menor número de casos possível. Primeiro, devemos definir as classes de equivalência : - Classes válidas (devemos testar pelo menos um caso de cada): Classe 1: 10,5 cm × 14,8 cm Classe 2: 14,8 cm × 21,0 cm Classe 3: 21,0 cm × 29,7 cm Classe 4: 29,7 cm × 42,0 cm - Classes inválidas (devemos testar pelo menos um caso de cada): Classe 5: Folhas menores que 10,5 cm (exemplo: 9 cm × 12 cm) Classe 6: Folhas maiores que 42 cm (exemplo: 50 cm × 60 cm) Em seguida, devemos determinar o número mínimo de testes. Para cobrir todas as classes de equivalência, precisamos de pelo menos seis testes: quatro testes para os tamanhos válidos; um teste para a classe inválida menor que 10,5 cm; e um teste para a classe inválida maior que 42 cm. Logo, eu discordo do gabarito definitivo que considerou apenas quatro casos de testes.
Other fields (not shown on cards):
back: Letra D - A técnica de particionamento de equivalência busca identificar classes válidas e inválidas, garantindo testes representativos com o menor número de casos possível. Primeiro, devemos definir as classes de equivalência : - Classes válidas (devemos testar pelo menos um caso de cada): Classe 1: 10,5 cm × 14,8 cm Classe 2: 14,8 cm × 21,0 cm Classe 3: 21,0 cm × 29,7 cm Classe 4: 29,7 cm × 42,0 cm - Classes inválidas (devemos testar pelo menos um caso de cada): Classe 5: Folhas menores que 10,5 cm (exemplo: 9 cm × 12 cm) Classe 6: Folhas maiores que 42 cm (exemplo: 50 cm × 60 cm) Em seguida, devemos determinar o número mínimo de testes. Para cobrir todas as classes de equivalência, precisamos de pelo menos seis testes: quatro testes para os tamanhos válidos; um teste para a classe inválida menor que 10,5 cm; e um teste para a classe inválida maior que 42 cm. Logo, eu discordo do gabarito definitivo que considerou apenas quatro casos de testes.

front: (CESPE / MPE-RO – 2023) O teste de integração de software é responsável por:
a) examinar os módulos desenvolvidos sem considerar acoplamento.
b) iniciar a recuperação de um sistema após uma falha.
c) analisar a forma como um sistema se comporta quando seus recursos são muito acessados.
d) validar, de forma conjunta, os módulos construídos individualmente.
e) verificar se os mecanismos de proteção de um software impedem acessos indevidos.
response: Letra D
comment: (a) Errado. O teste de integração de software foca precisamente no acoplamento entre módulos, testando como eles interagem entre si. Examinar módulos isoladamente sem considerar acoplamento seria o objetivo de testes unitários. (b) Errado. Recuperação de um sistema após uma falha é um aspecto de teste de recuperação ou resiliência, não de integração. Ele verifica a capacidade do sistema de retornar a um estado operacional após uma falha. (c) Errado. Analisar a forma como um sistema se comporta quando seus recursos são muito acessados é característico de testes de desempenho ou carga, que avaliam como o sistema lida com grandes volumes de uso. (d) Correto. O teste de integração é responsável por validar, de forma conjunta, os módulos construídos individualmente, verificando se eles funcionam corretamente quando combinados. Este teste foca nas interfaces e interações entre módulos ou subsistemas. (e) Errado. Verificar se os mecanismos de proteção de um software impedem acessos indevidos é tarefa de testes de segurança, que avaliam a eficácia das medidas de proteção contra ameaças e acessos não autorizados.
Other fields (not shown on cards):
back: Letra D - (a) Errado. O teste de integração de software foca precisamente no acoplamento entre módulos, testando como eles interagem entre si. Examinar módulos isoladamente sem considerar acoplamento seria o objetivo de testes unitários. (b) Errado. Recuperação de um sistema após uma falha é um aspecto de teste de recuperação ou resiliência, não de integração. Ele verifica a capacidade do sistema de retornar a um estado operacional após uma falha. (c) Errado. Analisar a forma como um sistema se comporta quando seus recursos são muito acessados é característico de testes de desempenho ou carga, que avaliam como o sistema lida com grandes volumes de uso. (d) Correto. O teste de integração é responsável por validar, de forma conjunta, os módulos construídos individualmente, verificando se eles funcionam corretamente quando combinados. Este teste foca nas interfaces e interações entre módulos ou subsistemas. (e) Errado. Verificar se os mecanismos de proteção de um software impedem acessos indevidos é tarefa de testes de segurança, que avaliam a eficácia das medidas de proteção contra ameaças e acessos não autorizados.

front: (CESPE / DATAPREV – 2023) No teste de acompanhamento, um grupo é designado para verificar quaisquer problemas que necessitem ser resolvidos e quaisquer alterações que devam ser feitas no ambiente de recuperação de desastres.
response: Correto
comment: No teste de acompanhamento, um grupo é designado para verificar problemas que precisam ser resolvidos e quaisquer alterações que devem ser feitas no ambiente de recuperação de desastres. Este processo assegura que as estratégias de recuperação estão atualizadas e funcionais, identificando falhas e áreas de melhoria para garantir a continuidade dos negócios em caso de desastre.
Other fields (not shown on cards):
back: Correto - No teste de acompanhamento, um grupo é designado para verificar problemas que precisam ser resolvidos e quaisquer alterações que devem ser feitas no ambiente de recuperação de desastres. Este processo assegura que as estratégias de recuperação estão atualizadas e funcionais, identificando falhas e áreas de melhoria para garantir a continuidade dos negócios em caso de desastre.

front: (CESPE / TBG – 2023) Os testes dos tipos alfa e beta são executados em um ambiente controlado e com a presença de, pelo menos, um desenvolvedor.
response: Errado
comment: Os testes alfa e beta são tipos distintos de testes de aceitação realizados em diferentes ambientes: Teste Alfa: executado em um ambiente controlado, geralmente nas instalações do desenvolvedor, e pode envolver a presença de desenvolvedores. Este teste é realizado antes do lançamento do produto para um público restrito, como a equipe interna ou um grupo seleto de usuários. Teste Beta: realizado em um ambiente real pelos usuários finais, sem a presença direta dos desenvolvedores. Esse teste visa identificar problemas que não foram detectados durante o teste alfa, oferecendo uma visão mais ampla do desempenho do software no mundo real.
Other fields (not shown on cards):
back: Errado - Os testes alfa e beta são tipos distintos de testes de aceitação realizados em diferentes ambientes: Teste Alfa: executado em um ambiente controlado, geralmente nas instalações do desenvolvedor, e pode envolver a presença de desenvolvedores. Este teste é realizado antes do lançamento do produto para um público restrito, como a equipe interna ou um grupo seleto de usuários. Teste Beta: realizado em um ambiente real pelos usuários finais, sem a presença direta dos desenvolvedores. Esse teste visa identificar problemas que não foram detectados durante o teste alfa, oferecendo uma visão mais ampla do desempenho do software no mundo real.

front: (CESPE / TBG – 2023) O teste de regressão deve ser efetuado para garantir que novos componentes não tenham causado problema nas funções que antes funcionavam corretamente.
response: Correto
comment: O teste de regressão é essencial para assegurar que alterações recentes no software, como a adição de novos componentes, correções de bugs ou atualizações, não introduziram problemas em funcionalidades que anteriormente funcionavam corretamente. Esse tipo de teste verifica se o comportamento do sistema permanece estável após mudanças, ajudando a identificar e corrigir possíveis regressões no código.
Other fields (not shown on cards):
back: Correto - O teste de regressão é essencial para assegurar que alterações recentes no software, como a adição de novos componentes, correções de bugs ou atualizações, não introduziram problemas em funcionalidades que anteriormente funcionavam corretamente. Esse tipo de teste verifica se o comportamento do sistema permanece estável após mudanças, ajudando a identificar e corrigir possíveis regressões no código.

front: (CESPE / BANRISUL – 2022) Na gestão de defeitos, o princípio de teste da regra 10 de Myers estabelece que as atividades de teste estático e dinâmico devem ser planejadas muito antes de serem iniciadas.
response: Errado
comment: Na verdade, a Regra 10 de Myers indica que o custo da correção de um defeito tende a ser cada vez maior quanto mais tarde ele for descoberto. Defeitos encontrados nas fases iniciais da etapa de desenvolvimento do software são mais baratos de serem corrigidos do que aqueles encontrados na produção.
Other fields (not shown on cards):
back: Errado - Na verdade, a Regra 10 de Myers indica que o custo da correção de um defeito tende a ser cada vez maior quanto mais tarde ele for descoberto. Defeitos encontrados nas fases iniciais da etapa de desenvolvimento do software são mais baratos de serem corrigidos do que aqueles encontrados na produção.

front: (CESPE / BANRISUL – 2022) No teste de fumaça (smoke test), os códigos do software são integrados em componentes bloqueadores de erros com módulos reutilizáveis necessários para implementar as funções do software.
response: Errado
comment: Vamos lá! Teste de Fumaça é uma abordagem de teste de integração comumente usada quando um produto de software é desenvolvido. Ele é projetado como um mecanismo de acompanhamento para projetos de tempo crítico, permitindo que a equipe de software avalie o projeto com frequência. Ele busca descobrir erros do tipo “show-stopper”, que têm a maior probabilidade de atrasar o calendário do projeto. Dito isso, esse item é uma viagem total! O Teste de Fumaça é um teste projetado para verificar se o software pode ser testado. Sabe aqueles erros tão básicos que impedem até o próprio teste? Pois é! Eu acredito que a banca traduziu mal “show-stopper error” como “componentes bloqueadores de erros”. Enfim, nada faz sentido nesse item. Se alguém tiver alguma explicação melhor, podem mandar no nosso fórum :)
Other fields (not shown on cards):
back: Errado - Vamos lá! Teste de Fumaça é uma abordagem de teste de integração comumente usada quando um produto de software é desenvolvido. Ele é projetado como um mecanismo de acompanhamento para projetos de tempo crítico, permitindo que a equipe de software avalie o projeto com frequência. Ele busca descobrir erros do tipo “show-stopper”, que têm a maior probabilidade de atrasar o calendário do projeto. Dito isso, esse item é uma viagem total! O Teste de Fumaça é um teste projetado para verificar se o software pode ser testado. Sabe aqueles erros tão básicos que impedem até o próprio teste? Pois é! Eu acredito que a banca traduziu mal “show-stopper error” como “componentes bloqueadores de erros”. Enfim, nada faz sentido nesse item. Se alguém tiver alguma explicação melhor, podem mandar no nosso fórum :)

front: (CESPE / BANRISUL – 2022) É possível que um defeito que resida em código sem causar uma falha não seja encontrado em um teste dinâmico.
response: Correto
comment: Teste dinâmico é um tipo de teste de software no qual o código sendo testado é executado. Ele é usado para testar a lógica de programação, as interfaces de usuário e as APIs, bem como para verificar a integridade de um código. Testes dinâmicos só verificam se o código está funcionando como esperado. Se um defeito estiver presente no código, mas não estiver causando nenhuma falha, então ele não será encontrado no teste dinâmico, pois o código estará funcionando como esperado.
Other fields (not shown on cards):
back: Correto - Teste dinâmico é um tipo de teste de software no qual o código sendo testado é executado. Ele é usado para testar a lógica de programação, as interfaces de usuário e as APIs, bem como para verificar a integridade de um código. Testes dinâmicos só verificam se o código está funcionando como esperado. Se um defeito estiver presente no código, mas não estiver causando nenhuma falha, então ele não será encontrado no teste dinâmico, pois o código estará funcionando como esperado.

front: (CESPE / BANRISUL – 2022) O teste estático é uma técnica de verificação de software que revisa o código do programa para identificar se ele representa as especificações produzidas para o software.
response: Correto
comment: Perfeito! O teste estático é uma ótima maneira de identificar possíveis erros no código antes mesmo de executar o programa. Ele pode ajudar a reduzir o tempo e os custos associados ao processo de desenvolvimento de software, pois os erros podem ser detectados e corrigidos mais rapidamente. Além disso, o teste estático também pode melhorar a qualidade do software, pois permite que os erros sejam identificados e corrigidos antes que o programa seja liberado para o usuário final.
Other fields (not shown on cards):
back: Correto - Perfeito! O teste estático é uma ótima maneira de identificar possíveis erros no código antes mesmo de executar o programa. Ele pode ajudar a reduzir o tempo e os custos associados ao processo de desenvolvimento de software, pois os erros podem ser detectados e corrigidos mais rapidamente. Além disso, o teste estático também pode melhorar a qualidade do software, pois permite que os erros sejam identificados e corrigidos antes que o programa seja liberado para o usuário final.

front: (CESPE / BANRISUL – 2022) Os testes de estresse devem verificar o uso da memória ao longo do tempo para garantir que não existam perdas acumulativas.
response: Errado
comment: Os testes de estresse são usados para verificar a capacidade de um sistema de suportar um alto volume de tráfego. Eles não são projetados para verificar o uso da memória ao longo do tempo. Na verdade, a questão trata de Testes de Resistência.
Other fields (not shown on cards):
back: Errado - Os testes de estresse são usados para verificar a capacidade de um sistema de suportar um alto volume de tráfego. Eles não são projetados para verificar o uso da memória ao longo do tempo. Na verdade, a questão trata de Testes de Resistência.

front: (CESPE / BANRISUL – 2022) O objetivo do teste de integração é verificar se os requisitos atendem a especificação e se as funcionalidades do sistema foram implementadas corretamente, sendo todo o sistema testado de modo a simular um ambiente de execução real.
response: Errado
comment: Opa… esse é o objetivo do Teste de Sistema. O Teste de Integração é um tipo de teste de software que verifica se diferentes partes do sistema estão integradas corretamente. É um tipo de teste de sistema específico projetado para verificar se as partes do sistema funcionam corretamente juntas.
Other fields (not shown on cards):
back: Errado - Opa… esse é o objetivo do Teste de Sistema. O Teste de Integração é um tipo de teste de software que verifica se diferentes partes do sistema estão integradas corretamente. É um tipo de teste de sistema específico projetado para verificar se as partes do sistema funcionam corretamente juntas.

front: (CESPE / BANRISUL – 2022) Os testes unitários são realizados com o objetivo de isolar cada parte do sistema para garantir que elas estejam funcionando conforme especificado.
response: Correto
comment: Testes unitários são testes de software que são realizados em partes individuais de um aplicativo ou sistema. Os testes unitários isolam cada parte do sistema para garantir que elas estejam funcionando como esperado, por exemplo, verificando se a entrada de dados está sendo processada corretamente, se as saídas estão de acordo com o esperado e se a lógica interna está funcionando corretamente. Ao realizar testes unitários, também é possível verificar se o código está executando como esperado em todos os níveis, o que reduz o risco de erros de código.
Other fields (not shown on cards):
back: Correto - Testes unitários são testes de software que são realizados em partes individuais de um aplicativo ou sistema. Os testes unitários isolam cada parte do sistema para garantir que elas estejam funcionando como esperado, por exemplo, verificando se a entrada de dados está sendo processada corretamente, se as saídas estão de acordo com o esperado e se a lógica interna está funcionando corretamente. Ao realizar testes unitários, também é possível verificar se o código está executando como esperado em todos os níveis, o que reduz o risco de erros de código.

front: (CESPE / BANRISUL – 2022) O teste unitário é o processo de testar os componentes de programa, como métodos ou classes de objeto.
response: Correto
comment: Teste unitário é uma técnica de teste de software que envolve a verificação de cada componente individual de um programa. Os testes são realizados para garantir que cada parte do programa funcione de forma adequada e forneça resultados corretos. Os testes unitários são executados a cada vez que uma alteração é feita no código, para garantir que todas as alterações sejam devidamente consideradas. Os testes podem ser realizados em métodos ou classes de objeto, variáveis, instruções de controle e até em funções de APIs.
Other fields (not shown on cards):
back: Correto - Teste unitário é uma técnica de teste de software que envolve a verificação de cada componente individual de um programa. Os testes são realizados para garantir que cada parte do programa funcione de forma adequada e forneça resultados corretos. Os testes unitários são executados a cada vez que uma alteração é feita no código, para garantir que todas as alterações sejam devidamente consideradas. Os testes podem ser realizados em métodos ou classes de objeto, variáveis, instruções de controle e até em funções de APIs.

front: (CESPE / BANRISUL – 2022) Ao se testarem as classes do objeto, devem-se testar as amostras de operações a ele associadas, não havendo necessidade de simular todos os eventos que causam mudança de estado.
response: Errado
comment: O teste unitário é o processo de testar os componentes de programa, como métodos ou classes de objeto. As funções individuais ou métodos são o tipo mais simples de componente. Seus testes devem ser chamadas para essas rotinas com parâmetros diferentes de entrada. Você pode usar as abordagens para projeto de casos de teste para projetar testes de funções ou métodos. Quando você está testando as classes de objeto, deve projetar os testes para fornecer uma cobertura de todas as características do objeto. Isso significa que você deve: Testar todas as operações associadas ao objeto; Definir e verificar o valor de todos os atributos associados ao objeto; Colocar o objeto em todos os estados possíveis, o que significa simular todos os eventos que causam mudanças de estado.
Other fields (not shown on cards):
back: Errado - O teste unitário é o processo de testar os componentes de programa, como métodos ou classes de objeto. As funções individuais ou métodos são o tipo mais simples de componente. Seus testes devem ser chamadas para essas rotinas com parâmetros diferentes de entrada. Você pode usar as abordagens para projeto de casos de teste para projetar testes de funções ou métodos. Quando você está testando as classes de objeto, deve projetar os testes para fornecer uma cobertura de todas as características do objeto. Isso significa que você deve: Testar todas as operações associadas ao objeto; Definir e verificar o valor de todos os atributos associados ao objeto; Colocar o objeto em todos os estados possíveis, o que significa simular todos os eventos que causam mudanças de estado.

front: (CESPE / BANRISUL – 2022) Devem ser escolhidos casos efetivos de teste unitário, o que significa que os casos de teste devem mostrar que, quando usado como esperado, o componente que se está testando faz o que ele é proposto a fazer e, se houver defeitos nos componentes, estes devem ser revelados por casos de teste.
response: Correto
comment: O teste é custoso e demorado, por isso é importante que você escolha casos efetivos de teste unitário. A efetividade, nesse caso, significa duas coisas: Os casos de teste devem mostrar que, quando usado como esperado, o componente que você está testando faz o que ele é proposto a fazer. Se houver defeitos nos componentes, estes devem ser revelados por casos de teste.
Other fields (not shown on cards):
back: Correto - O teste é custoso e demorado, por isso é importante que você escolha casos efetivos de teste unitário. A efetividade, nesse caso, significa duas coisas: Os casos de teste devem mostrar que, quando usado como esperado, o componente que você está testando faz o que ele é proposto a fazer. Se houver defeitos nos componentes, estes devem ser revelados por casos de teste.

front: (CESPE / TRT-AP-PA – 2022) A respeito de testes automatizados, no contexto de DevOps e DevSecOps, assinale a opção correta.
a) Em um teste unitário, os métodos da classe sendo testada e suas dependências podem ter relação com recursos externos.
b) Os bugs são detectados no final do ciclo de desenvolvimento, o que pode aumentar o tempo na criação de novos produtos.
c) Os testes unitários são testes de caixa preta com cada função que compõe o software.
d) O TDD (Test Driven Development) eleva o nível dos testes unitários e tem como característica criar a classe de testes antes da classe de produção, de forma que os testes guiem o código a ser implementado.
e) Os testes de integração são caracterizados pela verificação de partes internas do sistema, que se inter-relacionam entre si, conforme definido pelos clientes.
response: Letra D
comment: (a) Errado. Na verdade, idealmente ele não pode ter relação com recursos externos para garantir que o teste seja o mais autônomo possível e não seja influenciado por mudanças nos recursos externos. Quando há dependências externas, o teste se torna mais complexo e pode falhar de forma inconsistente ao longo do tempo; (b) Errado. Idealmente, bugs devem ser detectados o quanto antes para evitar retrabalho; (c) Errado, testes unitários não são testes caixa-preta - eles visam testar a funcionalidade de uma unidade com base em sua estrutura; (d) Correto. TDD é uma excelente abordagem para o desenvolvimento de software, pois permite que o código seja criado de acordo com a especificação desejada. Ele também ajuda a melhorar a qualidade do código, pois os testes unitários são executados antes da produção e validados; (e) Errado. Testes de integração não são caracterizados pela verificação de partes internas do sistema, mas sim pela verificação de como partes externas funcionam em conjunto. A integração testa a comunicação entre sistemas, o fluxo de dados entre sistemas e a interoperabilidade entre sistemas.
Other fields (not shown on cards):
back: Letra D - (a) Errado. Na verdade, idealmente ele não pode ter relação com recursos externos para garantir que o teste seja o mais autônomo possível e não seja influenciado por mudanças nos recursos externos. Quando há dependências externas, o teste se torna mais complexo e pode falhar de forma inconsistente ao longo do tempo; (b) Errado. Idealmente, bugs devem ser detectados o quanto antes para evitar retrabalho; (c) Errado, testes unitários não são testes caixa-preta - eles visam testar a funcionalidade de uma unidade com base em sua estrutura; (d) Correto. TDD é uma excelente abordagem para o desenvolvimento de software, pois permite que o código seja criado de acordo com a especificação desejada. Ele também ajuda a melhorar a qualidade do código, pois os testes unitários são executados antes da produção e validados; (e) Errado. Testes de integração não são caracterizados pela verificação de partes internas do sistema, mas sim pela verificação de como partes externas funcionam em conjunto. A integração testa a comunicação entre sistemas, o fluxo de dados entre sistemas e a interoperabilidade entre sistemas.

front: (CESPE / BNB – 2022) Na seleção de casos para os testes de unidade, uma estratégia eficaz é a do teste baseado em diretriz, em que os casos são escolhidos com base nas indicações geradas a partir de erros mais comuns identificados no desenvolvimento dos programas.
response: Correto
comment: Existem duas estratégias que podem ser eficazes para ajudar você a escolher casos de teste. São elas: Teste de Partição, em que você identifica os grupos de entradas que possuem características comuns e devem ser tratados da mesma maneira. Você deve escolher os testes dentro de cada um desses grupos. Testes baseados em Diretrizes, em que você usa as diretrizes de testes para escolher casos de teste. Essas diretrizes refletem a experiência anterior dos tipos de erros que os programadores cometem frequentemente no desenvolvimento de componentes.
Other fields (not shown on cards):
back: Correto - Existem duas estratégias que podem ser eficazes para ajudar você a escolher casos de teste. São elas: Teste de Partição, em que você identifica os grupos de entradas que possuem características comuns e devem ser tratados da mesma maneira. Você deve escolher os testes dentro de cada um desses grupos. Testes baseados em Diretrizes, em que você usa as diretrizes de testes para escolher casos de teste. Essas diretrizes refletem a experiência anterior dos tipos de erros que os programadores cometem frequentemente no desenvolvimento de componentes.

front: (CESPE / BNB – 2022) O teste com base em casos de uso é um procedimento efetivo para se alcançar o resultado pretendido com um teste de integração do sistema.
response: Correto
comment: O teste com base em casos de uso é um dos métodos mais comuns usados para testar a integração entre os componentes de um sistema. Ele é eficaz na verificação de se um sistema atende aos requisitos e funciona como deveria. Os casos de uso podem ser usados para descrever a função esperada de um sistema, e esta descrição pode ser usada como um guia para realizar o teste. Os testadores podem usar os casos de uso para validar o sistema, certificando-se de que todas as funcionalidades sejam executadas de acordo com o esperado e que não haja erros.
Other fields (not shown on cards):
back: Correto - O teste com base em casos de uso é um dos métodos mais comuns usados para testar a integração entre os componentes de um sistema. Ele é eficaz na verificação de se um sistema atende aos requisitos e funciona como deveria. Os casos de uso podem ser usados para descrever a função esperada de um sistema, e esta descrição pode ser usada como um guia para realizar o teste. Os testadores podem usar os casos de uso para validar o sistema, certificando-se de que todas as funcionalidades sejam executadas de acordo com o esperado e que não haja erros.

front: (CESPE / BNB – 2022) O teste automatizado usualmente é mais apropriado que o teste manual quando a interface do usuário do aplicativo muda consideravelmente em prazos curtos e a automação de teste ainda não está disponível.
response: Errado
comment: Na verdade, ele é mais apropriado quando a interface de usuário não muda consideravelmente em prazos curtos, sendo melhor empregado em processos repetitivos. Em geral, não compensa o esforço de se criar um teste automatizado para algo que mudará com frequência.
Other fields (not shown on cards):
back: Errado - Na verdade, ele é mais apropriado quando a interface de usuário não muda consideravelmente em prazos curtos, sendo melhor empregado em processos repetitivos. Em geral, não compensa o esforço de se criar um teste automatizado para algo que mudará com frequência.

front: (CESPE / TJ-AM – 2019) Erro e defeito são conceitos distintos: erro pode ser o resultado de uma falha; defeito é uma imperfeição ou inconsistência no produto do software ou em seu processo.
response: Correto
comment: Exato! O erro pode ser um resultado de um defeito ou uma falha, como um retorno esperado, que por causa de uma falha teve um valor diferente do que esperado. Já o defeito é qualquer imperfeição ou inconsistência no produto do software ou em seu processo, um defeito é também uma não conformidade. O Defeito faz parte do produto, é algo que esta implementada no código de maneira errada.
Other fields (not shown on cards):
back: Correto - Exato! O erro pode ser um resultado de um defeito ou uma falha, como um retorno esperado, que por causa de uma falha teve um valor diferente do que esperado. Já o defeito é qualquer imperfeição ou inconsistência no produto do software ou em seu processo, um defeito é também uma não conformidade. O Defeito faz parte do produto, é algo que esta implementada no código de maneira errada.

front: (CESPE / TJ-AM – 2019) Validação refere-se a um conjunto de atividades destinadas a garantir que o sistema esteja de acordo com os requisitos do usuário.
response: Correto
comment: Perfeito! Em um teste de validação os requisitos estabelecidos como parte dos requisitos de modelagem são validados em relação ao software criado. Em suma, a validação tem sucesso quando o software funciona de uma maneira que pode ser razoavelmente esperada pelo cliente
Other fields (not shown on cards):
back: Correto - Perfeito! Em um teste de validação os requisitos estabelecidos como parte dos requisitos de modelagem são validados em relação ao software criado. Em suma, a validação tem sucesso quando o software funciona de uma maneira que pode ser razoavelmente esperada pelo cliente

front: (CESPE / TJ-AM – 2019) O teste caixa preta trata o software como uma caixa cujo conteúdo é desconhecido e da qual só é possível visualizar os dados de entrada fornecidos e as respostas produzidas como saída.
response: Correto
comment: Perfeita definição! O teste de caixa-preta não tem acesso às estruturas internas do software, ele se foca nas saídas geradas em resposta a entradas escolhidas e condições especificadas.
Other fields (not shown on cards):
back: Correto - Perfeita definição! O teste de caixa-preta não tem acesso às estruturas internas do software, ele se foca nas saídas geradas em resposta a entradas escolhidas e condições especificadas.

front: (CESPE / TJ-AM – 2019) O teste de esforço é uma continuidade do teste de carga, e ambos são modalidades do teste de desempenho.
response: Correto
comment: O teste de desempenho (ou performance) é projetado para testar o desempenho em tempo de execução do software dentro do contexto de um sistema integrado. O teste de esforço e o teste de carga são modalidades do teste de desempenho, sendo que o teste de esforço (estresse) – normalmente – é realizado após o teste de carga.
Other fields (not shown on cards):
back: Correto - O teste de desempenho (ou performance) é projetado para testar o desempenho em tempo de execução do software dentro do contexto de um sistema integrado. O teste de esforço e o teste de carga são modalidades do teste de desempenho, sendo que o teste de esforço (estresse) – normalmente – é realizado após o teste de carga.

front: (CESPE / TJ-AM – 2019) O teste de integração descendente da modalidade primeiro em largura (breadth-first) move-se pela hierarquia de controle e integra todos os componentes em um caminho selecionado como principal.
response: Errado
comment: Na verdade, trata-se do teste de integração descendente da modalidade primeiro em profundidade. De acordo com Pressman, a integração primeiro-em-profundidade integra todos os componentes em um caminho de controle principal da estrutura do programa. A seleção de um caminho principal é, de certa forma, arbitrária e depende das características específicas da aplicação.
Other fields (not shown on cards):
back: Errado - Na verdade, trata-se do teste de integração descendente da modalidade primeiro em profundidade. De acordo com Pressman, a integração primeiro-em-profundidade integra todos os componentes em um caminho de controle principal da estrutura do programa. A seleção de um caminho principal é, de certa forma, arbitrária e depende das características específicas da aplicação.

front: (CESPE / MC-PA – 2019) Consoante os princípios dos métodos ágeis, na construção de um sistema, os testes de unidade do código criado devem ser sempre executados primeiramente:
a) pela equipe de testes, somente.
b) pela equipe de testes e pelo gerente do projeto.
c) pelo gerente do projeto, somente.
d) pelo programador.
e) pelo programador com o apoio da equipe de testes.
response: Letra D
comment: Os testes de unidade geralmente são feitos pelos próprios desenvolvedores de maneira mais informal e, não, por especialistas em testes.
Other fields (not shown on cards):
back: Letra D - Os testes de unidade geralmente são feitos pelos próprios desenvolvedores de maneira mais informal e, não, por especialistas em testes.

front: (CESPE / FUB – 2018) Os testes de caixa-branca buscam verificar o comportamento interno do software, ou seja, os elementos relacionados ao código-fonte desse software.
response: Correto
comment: Perfeito! A ideia da técnica de caixa-branca é testar a estrutura interna do software, isto é, seu código-fonte em si.
Other fields (not shown on cards):
back: Correto - Perfeito! A ideia da técnica de caixa-branca é testar a estrutura interna do software, isto é, seu código-fonte em si.

front: (CESPE / BNB – 2018) Determinada equipe de desenvolvimento de softwares desejava realizar testes que avaliassem o comportamento do sistema por meio do estudo das entradas e das saídas relacionadas, sem validação da implementação do software e sem acesso ao seu código- fonte. Para isso, a equipe sugeriu a utilização dos testes de caixa-preta e de caixa-branca. Nessa situação, somente o teste tipo caixa-preta é corretamente aplicável, pois o tipo caixa-branca depende de acesso ao código-fonte do sistema.
response: Correto
comment: Perfeito! O teste em que não há acesso às estruturas internas do software é o teste de caixa-preta, dessa forma, o teste de caixa-branca não é aplicável pois ele tem acesso ao código-fonte.
Other fields (not shown on cards):
back: Correto - Perfeito! O teste em que não há acesso às estruturas internas do software é o teste de caixa-preta, dessa forma, o teste de caixa-branca não é aplicável pois ele tem acesso ao código-fonte.

front: (CESPE / BNB – 2018) Determinada equipe de desenvolvimento de softwares pretendia realizar testes que permitissem avaliar cenários com os quais os usuários reais do sistema pudessem se relacionar. Esses cenários deveriam descrever uma maneira de usar o sistema. Para isso, foram sugeridos os testes de release e de cenário. Nessa situação, será correto aplicar testes de cenários, que são incompatíveis com os de release, devendo a aplicação desses últimos ser descartada.
response: Errado
comment: Teste de cenário é uma abordagem de teste de release em que você imagina cenários típicos de uso e os usa para para desenvolver casos de teste para o sistema. Dessa forma, não há que se falar que os testes de cenário são incompatíveis com os testes de release.
Other fields (not shown on cards):
back: Errado - Teste de cenário é uma abordagem de teste de release em que você imagina cenários típicos de uso e os usa para para desenvolver casos de teste para o sistema. Dessa forma, não há que se falar que os testes de cenário são incompatíveis com os testes de release.

front: (CESPE / BNB – 2018) O planejamento de testes é governado pela necessidade de selecionar alguns poucos casos de teste de um grande conjunto de possíveis casos. O exame que avalia se um grupo de entrada de dados resultou nas saídas pretendidas, levando-se em consideração a especificação do programa, é denominado teste:
a) de stress.
b) da caixa preta.
c) da caixa branca.
d) da caixa cinza.
e) de integração.
response: Letra B
comment: O teste que não tem acesso às estruturas internas do software e focaliza-se nas entradas e saídas é o teste caixa-preta.
Other fields (not shown on cards):
back: Letra B - O teste que não tem acesso às estruturas internas do software e focaliza-se nas entradas e saídas é o teste caixa-preta.

front: (CESPE / STJ – 2018) Em um serviço de integração contínua, testes de unidade são executados automaticamente com a finalidade de detectar erros funcionais.
response: Correto
comment: Basicamente a questão quer saber se os testes de unidade podem ser utilizados de forma automatizada, e sim eles podem.
Other fields (not shown on cards):
back: Correto - Basicamente a questão quer saber se os testes de unidade podem ser utilizados de forma automatizada, e sim eles podem.

front: (CESPE / STJ – 2018) Enquanto os testes de unidade propiciam a qualidade externa, os testes de aceitação ajudam o desenvolvedor a avaliar a qualidade interna do código, dando feedback sobre o design dos módulos e permitindo a manutenção com menor custo.
response: Errado
comment: A questão inverteu os conceitos. Na verdade, os testes que propiciam qualidade externa são os testes de aceitação (validação), ou seja, aqueles que são testados por usuários finais. Já os testes de unidade avaliam a qualidade dos módulos ou componentes.
Other fields (not shown on cards):
back: Errado - A questão inverteu os conceitos. Na verdade, os testes que propiciam qualidade externa são os testes de aceitação (validação), ou seja, aqueles que são testados por usuários finais. Já os testes de unidade avaliam a qualidade dos módulos ou componentes.

front: (CESPE / STJ – 2018) Teste de software pode ser definido como o processo de execução de um programa ou sistema com a intenção de se verificar se o mesmo está de acordo com o planejado nas especificações dos seus requisitos.
response: Correto
comment: Perfeito! O teste de software é um processo voltado a atingir a confiabilidade do software. De fato, temos que o teste de software é um processo mais amplo que o teste de validação. No entanto, essa definição está mais associada ao teste de validação que focalizam ações e saídas, ou seja, se o software funciona conforme foi proposto em seus requisitos.
Other fields (not shown on cards):
back: Correto - Perfeito! O teste de software é um processo voltado a atingir a confiabilidade do software. De fato, temos que o teste de software é um processo mais amplo que o teste de validação. No entanto, essa definição está mais associada ao teste de validação que focalizam ações e saídas, ou seja, se o software funciona conforme foi proposto em seus requisitos.

front: (CESPE / ABIN – 2018) As ferramentas de execução do teste são classificadas como ferramentas de suporte para execução e registro e têm, como vantagem, o fato de não requererem um grande esforço para a obtenção de resultados expressivos.
response: Errado
comment: Não é porque o teste é automatizado que ele não exigirá grande esforço. Por exemplo, alguns testes automatizados podem levar um grande tempo para serem concluídos.
Other fields (not shown on cards):
back: Errado - Não é porque o teste é automatizado que ele não exigirá grande esforço. Por exemplo, alguns testes automatizados podem levar um grande tempo para serem concluídos.

front: (CESPE / ABIN – 2018) No teste funcional, que é uma das fases do processo de validação, não é necessário o conhecimento das estruturas internas do software.
response: Correto
comment: Exatamente isso! No teste funcional, também chamado de teste de caixa-preta, não há acesso às estruturas internas do software. Em suma, ele serve para analisar como o software deveria funcionar, ou seja, se o software está de acordo com os requisitos propostos para o mesmo.
Other fields (not shown on cards):
back: Correto - Exatamente isso! No teste funcional, também chamado de teste de caixa-preta, não há acesso às estruturas internas do software. Em suma, ele serve para analisar como o software deveria funcionar, ou seja, se o software está de acordo com os requisitos propostos para o mesmo.

front: (CESPE / ABIN – 2018) No teste de integração, o foco é a comunicação entre os módulos do software, não as suas funcionalidades; portanto, nessa fase, testes funcionais não podem ser utilizados.
response: Errado
comment: Testes de Integração verificam o funcionamento em conjunto dos componentes do sistema, se são chamados corretamente e se a transferência de dados acontece no tempo correto, por meio de suas interfaces. Dessa forma, não há nenhuma restrição em se utilizar os testes de caixa-preta (também chamados de testes funcionais) nessa etapa.
Other fields (not shown on cards):
back: Errado - Testes de Integração verificam o funcionamento em conjunto dos componentes do sistema, se são chamados corretamente e se a transferência de dados acontece no tempo correto, por meio de suas interfaces. Dessa forma, não há nenhuma restrição em se utilizar os testes de caixa-preta (também chamados de testes funcionais) nessa etapa.

front: (CESPE / STM – 2018) Em um processo de cascata, testes de sistemas testam todo o sistema, enquanto, em processos de desenvolvimento iterativo, será testado apenas um incremento a ser entregue ao cliente.
response: Correto
comment: De acordo com Sommerville: “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”.
Other fields (not shown on cards):
back: Correto - De acordo com Sommerville: “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”.

front: (CESPE / CGM DE JOÃO PESSOA-PB – 2018) O particionamento de equivalência é uma técnica de teste caixa-preta caracterizada por dividir o domínio de entrada de um módulo em classes de equivalência, a partir das quais casos de teste são derivados.
response: Correto
comment: A técnica de particionamento de equivalência é uma técnica de caixa-preta, ela permite otimizar o processo de testes por meio da separação das entradas em classes ou categorias diferentes.
Other fields (not shown on cards):
back: Correto - A técnica de particionamento de equivalência é uma técnica de caixa-preta, ela permite otimizar o processo de testes por meio da separação das entradas em classes ou categorias diferentes.

front: (CESPE / STM – 2018) Testes de regressão servem ao propósito de verificar se o sistema pode operar na carga necessária, fazendo-a regredir constantemente até que o comportamento de falha do sistema seja testado ou que defeitos sejam identificados.
response: Errado
comment: Carga? Nope! Testes de Regressão são executados para garantir que uma funcionalidade ou parte de um software já testado continue funcionando após o mesmo sofrer alguma implementação ou manutenção.
Other fields (not shown on cards):
back: Errado - Carga? Nope! Testes de Regressão são executados para garantir que uma funcionalidade ou parte de um software já testado continue funcionando após o mesmo sofrer alguma implementação ou manutenção.

front: (CESPE / STM – 2018) Em testes de integração, a estratégia de integração bottom-up integrará componentes de infraestrutura que fornecem serviços comuns, adicionando a eles componentes funcionais; para testar uma nova característica, pode ser necessário integrar componentes diferentes.
response: Correto
comment: O que é Bottom-Up? Eu construo, integro e testo componentes de infraestrutura que fornecem serviços comuns a vários outros componentes; são mais genéricos, ou seja, é aquela classe mais independente que presta serviço para outras e depois componentes funcionais em que eu testo componentes que realizam funcionalidades específicas, que são mais dependentes, que precisam de outras classes – então é do mais geral para o mais específico (no sentido de funcionalidades) e do menor para o maior (no sentido de tamanho). A abordagem top-down é o contrário, eu começo testando o sistema até chegar aos módulos, ou seja, do mais específico para o mais geral (no sentido de funcionalidade). Portanto, a questão está perfeita!
Other fields (not shown on cards):
back: Correto - O que é Bottom-Up? Eu construo, integro e testo componentes de infraestrutura que fornecem serviços comuns a vários outros componentes; são mais genéricos, ou seja, é aquela classe mais independente que presta serviço para outras e depois componentes funcionais em que eu testo componentes que realizam funcionalidades específicas, que são mais dependentes, que precisam de outras classes – então é do mais geral para o mais específico (no sentido de funcionalidades) e do menor para o maior (no sentido de tamanho). A abordagem top-down é o contrário, eu começo testando o sistema até chegar aos módulos, ou seja, do mais específico para o mais geral (no sentido de funcionalidade). Portanto, a questão está perfeita!

front: (CESPE / BNB – 2018) Uma equipe de desenvolvimento de softwares pretendia realizar testes de forma incremental durante o desenvolvimento de um programa, a fim de verificar se mudanças no programa não haviam nele introduzido novos bugs; para isso, foram sugeridos os testes unitários e de regressão. Nessa situação, será correto utilizar os testes unitários, mas não os testes de regressão, pois esses últimos não visam verificar novos bugs, mas sim, tão somente, avaliar as funcionalidades do sistema.
response: Errado
comment: Pelo contrário, esse é o principal teste responsável por verificar novos bugs inseridos no sistema.
Other fields (not shown on cards):
back: Errado - Pelo contrário, esse é o principal teste responsável por verificar novos bugs inseridos no sistema.