{"subject_id":"3a3cc48d009981609d33f457a864550e","topico":"Testes: pirâmide, unitário, integração, TDD, BDD (Gherkin); verificação × validação","stems":["No que se refere ao processo e à estratégia de teste de aplicações web e à ferramenta SonarQube, julgue os itens subsequentes.","A respeito de desenvolvimento de sistemas, julgue os itens a seguir.","A respeito de desenvolvimento de software, julgue os itens que se seguem.","No que se refere à integração de sistemas, à arquitetura de software, aos testes de software e aos bancos de dados, julgue os itens subsecutivos.","Acerca de arquitetura de aplicações, julgue os próximos itens.","A respeito dos processos de desenvolvimento de software cascata e iterativo, de projeto de software orientado a objetos, de testes e de validação de software, julgue os itens a seguir.","À luz das disposições da Resolução CNJ n.º 335/2020 e das Portarias CNJ n.º 252/2020, CNJ n.º 253/2020 e CNJ n.º 131/2021, todas referentes à Plataforma Digital do Poder Judiciário (PDPJ-Br), julgue os itens a seguir.","Acerca do ciclo de vida de software e do desenvolvimento de software, julgue os itens que se seguem.","Julgue os itens a seguir, relativos ao teste de estresse, a testes automatizados e à resiliência de aplicações.","Com base nas Resoluções CNJ n.º 335/2020, n.º 396/2021 e n.º 522/2023, bem como nas Portarias CNJ n.º 252/2020, n.º 253/2020, n.º 131/2021 e n.º 162/2021, julgue os itens a seguir.","Com relação ao padrão MVC (Model View Controller), a padrões de projeto e a orientação a objetos, julgue os itens subsequentes.","No que concerne à qualidade do código e de sistemas e à abordagem DevOps, julgue os itens subsequentes.","A respeito de aplicação de testes, julgue os itens subsecutivos.","A respeito de DevOps, GIT e testes de software, julgue os itens a seguir.","Julgue os itens a seguir, no que se refere à engenharia de software e à análise de requisitos.","Acerca de criptografia, de clean code, de refactoring e de JUnit, julgue os itens seguintes.","Acerca de engenharia de software, julgue os itens seguintes.","Julgue os itens a seguir, relacionados a desenvolvimento web em Java.","Julgue os itens subsequentes, acerca de testes de software.","Acerca dos testes de software e das ferramentas para automatização de testes, bem como do desenvolvimento orientado por comportamento, julgue os itens que se seguem.","A respeito de metodologias e técnicas prescritas pela engenharia de software para o desenvolvimento e para a gestão de produtos, julgue os itens que se seguem.","Julgue os itens que se seguem, a respeito de qualidade de software.","Julgue os próximos itens, que tratam de arquitetura de software, intranet e TDD.","Acerca de conceitos e técnicas do projeto de software, desenvolvimento orientado por comportamento (BDD) e desenvolvimento guiado por testes (TDD), julgue os itens subsequentes.","Em relação a metodologias ágeis de desenvolvimento de software, julgue os seguintes itens.","Acerca dos conceitos de engenharia de softwares, métodos ágeis, teste de software e estimativas, julgue os itens subsequentes.","Acerca de controles e testes de segurança para aplicações web, julgue o item seguinte.","Com relação a teste unitário em engenharia de software, julgue os itens a seguir.","Julgue os itens a seguir, relativos a gerenciamento do ciclo de vida do sistema.","Com relação à arquitetura de desenvolvimento de software, julgue os itens a seguir.","Acerca de metodologias ágeis de desenvolvimento, julgue os itens seguintes.","Acerca de qualidade de software, julgue os itens subsequentes.","Julgue os seguintes itens, relativos à engenharia de software.","Com base nos fundamentos da Engenharia de Software, julgue os itens a seguir relativos às decisões adequadas que devem ser tomadas pelas equipes de analistas quando do planejamento para o desenvolvimento de um novo sistema.","Acerca dos fundamentos e dos princípios da qualidade de software e da gestão da configuração, julgue os itens que se seguem.","Acerca do gerenciamento de resposta a incidente e testes de penetração, julgue os itens a seguir.","Nos itens que avaliarem conhecimentos de informática e(ou) tecnologia da informação informado o contrário, considere que todos os programas mencionados estão em configuração padrão e que não há restrições de Julgue os itens a seguir, acerca de CSS3, JMS, JSON e JUnit.","Acerca de testes de software, julgue os itens que se seguem.","A respeito da engenharia de software, julgue os seguintes itens.","Julgue os itens que se seguem, relativos a disciplinas do processo de desenvolvimento de software.","Julgue os itens que se seguem, a respeito de EJB, Clean Code, desenvolvimento orientado a testes, lógica de programação e paradigmas de programação.","Julgue os seguintes itens, relativos a métricas de qualidade de software, JUnit, SQL, Delphi e desenvolvimento mobile.","Com relação a criptografia, desenvolvimento orientado a testes (TDD — test driven development) e Hibernate, julgue os seguintes itens.","Julgue os próximos itens, referentes às metodologias de desenvolvimento de software.","Julgue os seguintes itens, relativos a testes de software.","A respeito de análise, projeto, implementação e testes de software, julgue os seguintes itens.","No que se refere ao teste de software, julgue os itens seguintes.","No que concerne a testes de software, julgue os itens que se seguem.","A respeito das tecnologias relacionadas ao desenvolvimento web em Java, julgue os itens a seguir.","A respeito dos níveis de maturidade de processos estabelecidos pelo MPS/BR para organizações que produzem software, julgue os itens subsequentes.","Acerca dos conceitos de análise e projeto de sistemas em engenharia de software, julgue os itens subsequentes."],"questions":[{"id":"dd5855967337","number":11,"stem":0,"statement":"Uma estratégia de teste para aplicações web contempla a execução da aplicação em múltiplas configurações de ambiente, de forma a avaliar não apenas a compatibilidade, mas também a confiabilidade, a escalabilidade e o desempenho da aplicação.","answer":"C","source":{"slug":"TCE_RS_25","ano":2025},"explanation":{"verdict_reason":"Aplicação web roda em ambiente que o desenvolvedor não controla: navegadores, sistemas operacionais, dispositivos e conexões diferentes. Por isso a estratégia de teste prevê execução em múltiplas configurações, e isso não serve só à compatibilidade: sob configurações e cargas variadas também se avaliam confiabilidade, escalabilidade e desempenho.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Teste de aplicação web em múltiplas configurações de ambiente","citation":null,"trap_note":"Em aplicação web, a dimensão de configuração é um eixo de teste por si só, ao lado de conteúdo, função, navegação, desempenho e segurança."}},{"id":"b624aacc6487","number":13,"stem":0,"statement":"A pirâmide para teste de aplicações web prevê um fluxo de processo da direita para a esquerda e adota uma estratégia bottom-up, em que os elementos de infraestrutura são testados antes dos componentes visíveis ao usuário.","answer":"E","source":{"slug":"TCE_RS_25","ano":2025},"explanation":{"verdict_reason":"O fluxo previsto para o teste de aplicações web é o inverso do descrito: começa pelo que está imediatamente visível ao usuário, conteúdo e interface, segue para navegação, projeto e componentes e só ao final alcança as camadas de infraestrutura, configuração, desempenho e segurança. O sentido do processo é da esquerda para a direita e de cima para baixo.","distortion_type":"inversao","distorted_span":"um fluxo de processo da direita para a esquerda e adota uma estratégia bottom-up","corrected_statement":"A pirâmide para teste de aplicações web prevê um fluxo de processo da esquerda para a direita e de cima para baixo, em que os componentes visíveis ao usuário são testados antes dos elementos de infraestrutura.","concept":"Teste de aplicação web começa pelo visível ao usuário e termina na infraestrutura","citation":null,"trap_note":"Não confunda as duas pirâmides: a pirâmide de testes, com base de unidade, fala de proporção entre níveis; a pirâmide de teste de aplicações web fala da ordem do processo, do visível para o profundo."}},{"id":"fdf837fa6060","number":64,"stem":1,"statement":"A recomendação do princípio timely de clean code visa a que os testes de unidade sejam elaborados antes do próprio código.","answer":"C","source":{"slug":"TELEBRAS_25","ano":2025},"explanation":{"verdict_reason":"Timely é o T dos princípios FIRST tratados no clean code e significa oportuno no tempo: o teste de unidade é escrito pouco antes do código de produção que o faz passar. Escrito depois, o teste tende a ser moldado pela implementação existente e deixa de influenciar o projeto do código.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Timely (FIRST): teste de unidade antes do código","citation":null,"trap_note":"Timely é a ponte entre clean code e TDD. Se um item citar timely e disser que o teste vem depois, contradisse a própria definição do princípio."}},{"id":"3a5cf185fdfb","number":65,"stem":2,"statement":"A finalidade do teste de carga é determinar como a aplicação em seu ambiente do lado do servidor responderá a várias condições de carga.","answer":"C","source":{"slug":"MP_CE_25_SERVIDOR","ano":2025},"explanation":{"verdict_reason":"O teste de carga observa o comportamento da aplicação, do lado do servidor, sob condições de carga variadas mas dentro do esperado: tempo de resposta, vazão e consumo de recursos conforme o número de usuários ou de transações cresce. É diferente do teste de estresse, que leva o sistema a condições anormais para achar o ponto de ruptura. A definição do item é exatamente a de carga.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Teste de carga: resposta do servidor a várias condições de carga","citation":null,"trap_note":"Carga mede o comportamento sob demanda esperada; estresse força além do previsto; desempenho mede tempo de resposta e vazão. Quando o item falar em aumentar a carga progressivamente até o desempenho ficar inaceitável, o nome certo é carga ou estresse, nunca aceitação, integração ou regressão."}},{"id":"80d104876315","number":65,"stem":3,"statement":"Os princípios FIRST orientam os testes automatizados a serem rápidos na execução, flexíveis na aplicação em diferentes contextos, independentes entre si, repetíveis consistentemente, autovalidáveis e oportunos na criação e execução.","answer":"E","source":{"slug":"STM_25","ano":2025},"explanation":{"verdict_reason":"FIRST é um acrônimo de cinco letras e cinco princípios: fast, independent, repeatable, self-validating e timely. O item lista corretamente esses cinco e insere um sexto, flexíveis em diferentes contextos, que não pertence ao conjunto. A lista é fechada, e acrescentar item a ela torna a afirmação falsa.","distortion_type":"troca_de_termo","distorted_span":"flexíveis na aplicação em diferentes contextos,","corrected_statement":"Os princípios FIRST orientam os testes automatizados a serem rápidos na execução, independentes entre si, repetíveis consistentemente, autovalidáveis e oportunos na criação e execução.","concept":"FIRST tem exatamente cinco princípios","citation":null,"trap_note":"Conte os elementos de todo acrônimo antes de julgar. Inserir um item plausível em lista fechada é um molde recorrente, e vale para FIRST, SOLID e para os processos de cada nível de maturidade."}},{"id":"4636b48f04d8","number":68,"stem":4,"statement":"De acordo com a abordagem test-driven development, os testes devem ser definidos antes da codificação das funções a serem testadas.","answer":"C","source":{"slug":"TELEBRAS_25","ano":2025},"explanation":{"verdict_reason":"É a regra de ordem que define o TDD: primeiro o teste, que necessariamente falha por não haver implementação, depois o código mínimo que o faz passar, depois a refatoração. O teste funciona como especificação executável da função que ainda será codificada.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"TDD: teste definido antes da codificação","citation":null,"trap_note":"Vermelho, verde, refatorar é a cadeia mínima. Qualquer item que descreva o TDD começando pelo código já está fora de ordem."}},{"id":"9738b2a2c9b7","number":86,"stem":5,"statement":"O teste de lançamento limita-se à verificação de novas funcionalidades de um release, sem a necessidade de reexecução de testes em funcionalidades já existentes.","answer":"E","source":{"slug":"FUB_25","ano":2025},"explanation":{"verdict_reason":"O teste de lançamento avalia a versão inteira que será entregue, e não apenas o que foi acrescentado. É justamente na entrega de uma nova versão que a regressão é obrigatória, porque a alteração pode ter quebrado funcionalidades que antes operavam corretamente. Dispensar a reexecução sobre o que já existia inverte a exigência.","distortion_type":"inversao","distorted_span":"sem a necessidade de reexecução de testes em funcionalidades já existentes","corrected_statement":"O teste de lançamento não se limita à verificação de novas funcionalidades de um release, exigindo a reexecução de testes em funcionalidades já existentes.","concept":"Teste de lançamento inclui regressão sobre o que já existia","citation":null,"trap_note":"Versão nova sem regressão é a receita do defeito reintroduzido. Sempre que um item dispensar a reexecução de testes antigos após mudança, o gabarito tende a ser errado."}},{"id":"d97ca563f14d","number":104,"stem":6,"statement":"As soluções constantes da PDPJ-Br devem conter artefatos de testes automatizados com incentivo às práticas de TDD (test driven development), dispondo de testes de unidade e de integração.","answer":"C","source":{"slug":"STM_25","ano":2025},"explanation":{"verdict_reason":"As normas do CNJ sobre a PDPJ-Br fixam padrões técnicos obrigatórios para as soluções da plataforma, e entre eles está a exigência de artefatos de testes automatizados, com incentivo expresso ao TDD e previsão de testes de unidade e de integração. O item reproduz essa exigência.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"PDPJ-Br: testes automatizados, TDD, unidade e integração","citation":null,"trap_note":"Nas normas da PDPJ-Br, o par citado é sempre unidade e integração, com incentivo ao TDD. Item que substitua esses níveis por outros, ou que torne os testes facultativos, está alterando o texto normativo."}},{"id":"6e4d3afc76d5","number":57,"stem":7,"statement":"Na etapa de projeto do ciclo de desenvolvimento de um software, realiza-se o teste final, ou teste de aceite.","answer":"E","source":{"slug":"MPO_24","ano":2024},"explanation":{"verdict_reason":"O teste de aceite é a última atividade de teste do ciclo, executada sobre o sistema construído e com participação do cliente, depois da implementação e dos testes de sistema. Na etapa de projeto ainda não existe código a executar: o que se faz ali é verificação estática dos artefatos de projeto e, no máximo, o planejamento dos testes.","distortion_type":"atribuicao_errada","distorted_span":"Na etapa de projeto do ciclo de desenvolvimento de um software","corrected_statement":"Na etapa final do ciclo de desenvolvimento de um software, após a implementação e os testes de sistema, realiza-se o teste final, ou teste de aceite.","concept":"Aceite ocorre ao final do ciclo, não na etapa de projeto","citation":null,"trap_note":"No modelo em V, cada etapa à esquerda tem o teste correspondente à direita: requisitos com aceitação, projeto de alto nível com sistema, projeto detalhado com integração, codificação com unidade. Planejar o teste é cedo; executá-lo é tarde."}},{"id":"667a917395f6","number":62,"stem":8,"statement":"O teste automatizado pode conter recursos de auditoria eletrônica com avaliadores e geradores automáticos de testes.","answer":"C","source":{"slug":"MPO_24","ano":2024},"explanation":{"verdict_reason":"A automação de teste não se limita a repetir roteiros gravados. Ela abrange geradores automáticos de casos de teste, a partir de especificações ou de modelos, e avaliadores que conferem automaticamente os resultados obtidos contra os esperados, registrando o que foi executado. É esse registro conferido que funciona como auditoria eletrônica.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Automação inclui geradores de casos e avaliadores de resultados","citation":null,"trap_note":"Teste autovalidável, o S do FIRST, é o mesmo princípio no nível da unidade: quem julga o resultado é o próprio teste, não uma pessoa lendo a saída."}},{"id":"150f0a656fc1","number":63,"stem":8,"statement":"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.","answer":"C","source":{"slug":"MPO_24","ano":2024},"explanation":{"verdict_reason":"O teste de estresse é definido pela anormalidade da condição: exige recursos em quantidade, frequência ou volume acima do previsto no projeto, para observar como o sistema se comporta no limite e além dele. É o que o distingue do teste de carga, que trabalha dentro das condições esperadas.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Teste de estresse: condições anormais de recurso, frequência ou volume","citation":null,"trap_note":"Estresse procura o ponto de ruptura e o modo de falhar; carga procura o comportamento sob demanda esperada. A palavra anormal é a marca do estresse."}},{"id":"e9cd8d89fc44","number":63,"stem":9,"statement":"As soluções presentes na PDPJ-Br deverão conter artefatos de testes automatizados com incentivo às práticas de TDD (test driven development), contando com testes de unidade e de integração.","answer":"C","source":{"slug":"CPNUJE_24","ano":2024},"explanation":{"verdict_reason":"O conjunto normativo do CNJ sobre a PDPJ-Br impõe às soluções da plataforma a entrega de artefatos de testes automatizados, com incentivo às práticas de TDD e previsão expressa de testes de unidade e de integração. O item reproduz a exigência sem alteração.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"PDPJ-Br: exigência de testes automatizados com TDD","citation":null,"trap_note":"Em item normativo, a alteração costuma ser de um substantivo: troca-se unidade por sistema, ou incentivo por vedação. Compare a lista citada com o par unidade e integração."}},{"id":"9565dda4e67c","number":63,"stem":10,"statement":"O padrão Singleton facilita o teste unitário, pois garante que sempre haverá uma única instância da classe para testar.","answer":"E","source":{"slug":"MP_TO_24_SERVIDOR","ano":2024},"explanation":{"verdict_reason":"O Singleton dificulta o teste unitário, em vez de facilitá-lo. A instância única é estado global compartilhado: o que um teste altera vaza para o próximo, quebrando o isolamento e a repetibilidade, e o acesso estático impede substituir a dependência por um dublê. Testabilidade é justamente a crítica clássica ao padrão.","distortion_type":"inversao","distorted_span":"facilita o teste unitário","corrected_statement":"O padrão Singleton dificulta o teste unitário, pois a instância única funciona como estado global compartilhado entre os testes e impede a substituição da dependência por um dublê.","concept":"Singleton compromete isolamento e independência dos testes","citation":null,"trap_note":"Teste de unidade exige poder trocar as dependências. Qualquer mecanismo que fixe uma instância global, estática ou implícita joga contra o I e o R do FIRST."}},{"id":"bce3eff4bc54","number":67,"stem":11,"statement":"Nos testes de software, os stubs, diferentemente dos mocks, são mais apropriados para a verificação do comportamento da aplicação em contraste com a verificação de estado durante um teste unitário.","answer":"E","source":{"slug":"CPNUJE_24","ano":2024},"explanation":{"verdict_reason":"Os papéis estão trocados. O stub apenas devolve respostas prontas para que o teste prossiga, e por isso apoia a verificação de estado, em que se examina o resultado final do objeto sob teste. O mock carrega expectativas sobre quais chamadas devem ocorrer e com quais argumentos, e é ele que serve à verificação de comportamento.","distortion_type":"inversao","distorted_span":"os stubs, diferentemente dos mocks, são mais apropriados para a verificação do comportamento da aplicação","corrected_statement":"Nos testes de software, os mocks, diferentemente dos stubs, são mais apropriados para a verificação do comportamento da aplicação em contraste com a verificação de estado durante um teste unitário.","concept":"Stub verifica estado; mock verifica comportamento","citation":null,"trap_note":"Guarde por dentro e por fora: o stub existe para alimentar o teste, o mock existe para cobrar do teste como as dependências foram usadas. É o par de dublês que a banca mais inverte."}},{"id":"593448a771e1","number":68,"stem":12,"statement":"Para facilitar os testes de uma aplicação, podem ser utilizados os mock objects, que são objetos genéricos que atendem a todas as necessidades de testes.","answer":"E","source":{"slug":"TRF6_24","ano":2024},"explanation":{"verdict_reason":"Mock não é objeto genérico nem universal. Cada mock é construído para um cenário: substitui uma dependência específica, com respostas e expectativas programadas para aquele teste. A afirmação de que atendem a todas as necessidades de teste generaliza um recurso que é, por natureza, sob medida e limitado.","distortion_type":"generalizacao","distorted_span":"objetos genéricos que atendem a todas as necessidades de testes","corrected_statement":"Para facilitar os testes de uma aplicação, podem ser utilizados os mock objects, que são objetos construídos para simular uma dependência específica, com respostas e expectativas programadas para determinado cenário de teste.","concept":"Mock é dublê específico de um cenário, não objeto universal","citation":null,"trap_note":"Todas as necessidades, qualquer situação e qualquer contexto são marcas de generalização indevida. Recurso de teste é sempre construído para um propósito delimitado."}},{"id":"c9a04fb92547","number":68,"stem":13,"statement":"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.","answer":"C","source":{"slug":"MP_GO_24_SERVIDOR","ano":2024},"explanation":{"verdict_reason":"O cenário descrito, execução rápida das funções principais para confirmar que não há falhas graves antes de prosseguir, é exatamente o propósito do teste de fumaça. Ele não busca cobertura ampla nem profundidade: busca decidir, em pouco tempo, se a versão está estável o bastante para ser testada com mais rigor.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Teste de fumaça: execução rápida das funções principais","citation":null,"trap_note":"Fumaça é amplitude sem profundidade: toca em tudo que é essencial, superficialmente. Regressão é o oposto no critério de seleção, pois olha o que a mudança pode ter quebrado."}},{"id":"ae4b364e7d65","number":68,"stem":11,"statement":"Um defeito como a complexidade excessiva do código pode, em princípio, ser encontrado com maior facilidade e com menores custos a partir da utilização de testes estáticos.","answer":"C","source":{"slug":"CPNUJE_24","ano":2024},"explanation":{"verdict_reason":"Complexidade excessiva é propriedade da estrutura do código, detectável por leitura e por métricas como a complexidade ciclomática, sem executar o programa. O teste estático a encontra cedo, antes de existir ambiente montado e massa de dados, o que reduz tanto o esforço quanto o custo da correção.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Teste estático encontra defeito de estrutura mais cedo e mais barato","citation":null,"trap_note":"Nem todo defeito é observável em execução. Complexidade, código morto, violação de padrão e vulnerabilidade de padrão conhecido são território do estático."}},{"id":"96c260380aa5","number":69,"stem":12,"statement":"Na utilização das técnicas de desenvolvimento guiado por testes (TDD), deve ser escrito um novo código apenas quando um teste automatizado falhar.","answer":"C","source":{"slug":"TRF6_24","ano":2024},"explanation":{"verdict_reason":"É a regra operacional que define o TDD: nenhum código de produção é escrito sem que haja antes um teste automatizado falhando que o exija. Essa disciplina garante que todo código nasça coberto e que nada seja implementado além do que algum teste demanda.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"TDD: código novo só quando um teste automatizado falha","citation":null,"trap_note":"Dessa regra decorrem duas consequências cobradas: cobertura por construção e ausência de código especulativo. O teste falhando é a autorização para escrever código."}},{"id":"3528d4bdaf01","number":86,"stem":14,"statement":"As principais características do teste em programação extrema (XP) são o desenvolvimento orientado a testes a partir de cenários com participação do usuário e o uso de frameworks automatizados para garantir qualidade contínua.","answer":"C","source":{"slug":"TRF6_24","ano":2024},"explanation":{"verdict_reason":"Na XP o teste é atividade central e tem duas faces: o desenvolvimento é guiado por testes de unidade escritos antes do código, e os testes de aceitação nascem dos cenários das histórias, definidos com participação do cliente presente na equipe. A prática só se sustenta com automação, porque a suíte é executada continuamente a cada integração.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"XP: TDD, cenários com o usuário e automação contínua","citation":null,"trap_note":"Cliente presente, teste automatizado e integração contínua andam juntos na XP. Item que descreva teste manual esporádico ou cliente ausente não está descrevendo XP."}},{"id":"6c03a3dc3884","number":94,"stem":15,"statement":"No JUnit, a anotação @EnabledOnOs permite que testes sejam executados em qualquer sistema operacional, garantindo que todas as funcionalidades sejam testadas uniformemente em diferentes plataformas.","answer":"E","source":{"slug":"STJ_24","ano":2024},"explanation":{"verdict_reason":"A anotação EnabledOnOs faz o contrário do que o item afirma: ela restringe a execução do teste aos sistemas operacionais listados, desabilitando-o nos demais. É um recurso de execução condicional, usado justamente quando o comportamento depende da plataforma, e não um mecanismo de execução uniforme em todas elas.","distortion_type":"inversao","distorted_span":"permite que testes sejam executados em qualquer sistema operacional","corrected_statement":"No JUnit, a anotação @EnabledOnOs permite que testes sejam executados apenas nos sistemas operacionais especificados, sendo desabilitados nos demais.","concept":"EnabledOnOs restringe a execução a sistemas operacionais específicos","citation":null,"trap_note":"Anotações de execução condicional do JUnit 5 habilitam ou desabilitam conforme um critério. Item que transforme filtro em garantia de universalidade inverteu a função."}},{"id":"50a574df0b0a","number":106,"stem":16,"statement":"O teste de unidade focaliza a verificação de aceitação do servidor de aplicação, ou seja, verifica se o software está sendo bem implementado pelo usuário.","answer":"E","source":{"slug":"SEPLAG_CE_24","ano":2024},"explanation":{"verdict_reason":"O teste de unidade exercita o menor componente implementável do software, método ou classe, e é conduzido pelo desenvolvedor contra a especificação daquele componente. Verificar aceitação, do ponto de vista do uso pelo usuário, é a finalidade do teste de aceitação, que está no outro extremo da escala de níveis.","distortion_type":"troca_de_termo","distorted_span":"a verificação de aceitação do servidor de aplicação","corrected_statement":"O teste de unidade focaliza a verificação do menor componente implementável do software, ou seja, verifica se cada módulo está sendo bem implementado pelo desenvolvedor.","concept":"Unidade × aceitação: menor componente contra especificação × sistema contra a necessidade do usuário","citation":null,"trap_note":"Unidade é o nível mais interno e mais técnico; aceitação é o mais externo e quem decide é o usuário. Item que ponha o usuário dentro do teste de unidade trocou os extremos da escala."}},{"id":"79d5f2931197","number":52,"stem":17,"statement":"O JUnit considera que os resultados de um teste unidade não devem depender da ordem de execução e não permite que se interfira na ordem de execução de métodos de teste.","answer":"E","source":{"slug":"CNMP_23","ano":2023},"explanation":{"verdict_reason":"A primeira metade está certa: o JUnit parte do princípio de que um teste não pode depender da ordem em que os demais rodaram. A segunda metade inverte um fato da ferramenta: ela permite, sim, fixar a ordem de execução dos métodos, por anotações como FixMethodOrder no JUnit 4 e TestMethodOrder com Order no JUnit 5. Não depender da ordem é uma recomendação de projeto, não uma proibição técnica.","distortion_type":"inversao","distorted_span":"não permite que se interfira na ordem de execução de métodos de teste","corrected_statement":"O JUnit considera que os resultados de um teste unidade não devem depender da ordem de execução, mas permite que se interfira na ordem de execução de métodos de teste.","concept":"Independência de ordem é princípio; fixar a ordem é possível no JUnit","citation":null,"trap_note":"Cuidado com itens que transformam boa prática em impossibilidade técnica. Não deve depender é diferente de não pode ser feito, e a banca explora exatamente essa distância."}},{"id":"350a7a9959cf","number":80,"stem":18,"statement":"No BDD, os nomes dos métodos de testes não são códigos, mas frases com significado real, a exemplo das histórias de usuários.","answer":"C","source":{"slug":"BCB_24","ano":2023},"explanation":{"verdict_reason":"O BDD move a escrita do teste para a linguagem do negócio: os nomes dos testes deixam de ser identificadores técnicos e passam a ser sentenças legíveis que descrevem comportamento esperado, no mesmo registro das histórias de usuário. É essa legibilidade que permite ao cliente participar da definição dos cenários.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"BDD nomeia testes como frases de comportamento, não como código","citation":null,"trap_note":"O eixo do BDD é a linguagem compartilhada com o negócio. Sempre que um item associar linguagem de domínio, histórias de usuário ou cenários legíveis, o rótulo correto é BDD, não TDD."}},{"id":"44030323afbc","number":81,"stem":18,"statement":"O TDD (test driven development) é um tipo de teste unitário em que a especificação de teste é escrita logo após o código para validar o comportamento desejado.","answer":"E","source":{"slug":"BCB_24","ano":2023},"explanation":{"verdict_reason":"No TDD o teste vem primeiro: escreve-se o teste que falha, depois o código mínimo que o faz passar, depois refatora-se. Escrever a especificação de teste após o código é a prática tradicional que o TDD justamente inverte. A ordem é o núcleo da técnica, e é ela que o item troca.","distortion_type":"inversao","distorted_span":"logo após o código","corrected_statement":"O TDD (test driven development) é um tipo de teste unitário em que a especificação de teste é escrita logo antes do código para validar o comportamento desejado.","concept":"TDD: teste antes do código","citation":null,"trap_note":"Esta é a pergunta mais repetida do tópico e sempre se resolve por uma palavra: antes ou depois. Localize o advérbio de tempo e julgue só ele."}},{"id":"3380c44ad5c4","number":84,"stem":19,"statement":"Em um teste de integração, cada uma das unidades é testada separadamente para se observar se elas funcionam de forma adequada.","answer":"E","source":{"slug":"SEFIN_FORTALEZA_CE_23","ano":2023},"explanation":{"verdict_reason":"Testar cada unidade separadamente é a definição de teste de unidade. O teste de integração pressupõe as unidades já testadas e se ocupa do que acontece entre elas: passagem de parâmetros, contratos de interface, suposições que um módulo faz sobre o outro. A descrição está correta; o nome colado nela é o do nível errado.","distortion_type":"troca_de_termo","distorted_span":"Em um teste de integração","corrected_statement":"Em um teste de unidade, cada uma das unidades é testada separadamente para se observar se elas funcionam de forma adequada.","concept":"Unidade testa isoladamente; integração testa as interfaces entre unidades","citation":null,"trap_note":"Leia a descrição antes do nome. Se a frase fala em isolar, o nível é unidade; se fala em interface, interação ou combinação de módulos, é integração; se fala em necessidade do cliente, é aceitação."}},{"id":"8408e0b0b891","number":85,"stem":19,"statement":"No desenvolvimento orientado por comportamento (BDD), as palavras-chave utilizadas nos blocos que formam os cenários são given, when e then.","answer":"C","source":{"slug":"SEFIN_FORTALEZA_CE_23","ano":2023},"explanation":{"verdict_reason":"No BDD os cenários são escritos em Gherkin, uma linguagem estruturada em três blocos: given (dado o contexto inicial), when (quando ocorre o evento) e then (então este é o resultado esperado). São exatamente essas as palavras-chave que delimitam os blocos do cenário.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Gherkin: given, when, then","citation":null,"trap_note":"Guarde a tríade given/when/then como assinatura do BDD. Quando um item citar outras palavras ou atribuir given/when/then ao TDD, ao Scrum ou a casos de uso, é troca de termo."}},{"id":"4aee226046be","number":86,"stem":19,"statement":"No particionamento de equivalências para a criação de casos de teste, devem ser consideradas apenas as partições válidas.","answer":"E","source":{"slug":"SEFIN_FORTALEZA_CE_23","ano":2023},"explanation":{"verdict_reason":"O particionamento de equivalência divide o domínio de entrada em classes válidas e inválidas, e deriva casos de teste de ambas. Testar só as partições válidas deixa sem cobertura todo o tratamento de erro, que é justamente onde os defeitos se concentram. A palavra apenas é o que torna o item falso.","distortion_type":"generalizacao","distorted_span":"apenas as partições válidas","corrected_statement":"No particionamento de equivalências para a criação de casos de teste, devem ser consideradas tanto as partições válidas quanto as inválidas.","concept":"Particionamento de equivalência cobre classes válidas e inválidas","citation":null,"trap_note":"Todo intervalo fechado gera três partições: abaixo do limite inferior, dentro e acima do limite superior. Item que reduza a cobertura à faixa válida está errado por construção."}},{"id":"b5df29667152","number":87,"stem":19,"statement":"Em um teste funcional de software, os elementos de uma classe devem se comportar de maneira equivalente.","answer":"C","source":{"slug":"SEFIN_FORTALEZA_CE_23","ano":2023},"explanation":{"verdict_reason":"O raciocínio funcional, de caixa-preta, apoia-se na hipótese de que os elementos de uma mesma classe de equivalência são processados do mesmo modo pelo programa. É essa hipótese que autoriza testar um único representante da classe em vez de todos os valores possíveis do domínio.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Classe de equivalência: elementos tratados de forma equivalente","citation":null,"trap_note":"A economia do teste funcional vem dessa hipótese: um representante por classe. Se os elementos não se comportassem de forma equivalente, não haveria classe e o teste exaustivo voltaria a ser necessário."}},{"id":"293cf4893eca","number":88,"stem":19,"statement":"Na análise do valor limite, casos de teste podem ser derivados dos domínios de entrada e de saída.","answer":"C","source":{"slug":"SEFIN_FORTALEZA_CE_23","ano":2023},"explanation":{"verdict_reason":"A análise do valor limite não se restringe ao domínio de entrada. Depois de escolher os valores nas fronteiras da entrada, a técnica também exercita as fronteiras do domínio de saída, buscando entradas que produzam os valores extremos que o programa pode devolver. Derivar casos dos dois domínios é parte da definição da técnica.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Valor limite: fronteiras de entrada e também de saída","citation":null,"trap_note":"Particionamento e valor limite são técnicas irmãs de caixa-preta: a primeira escolhe um representante no meio da classe, a segunda vai às bordas. Ambas podem olhar entrada e saída."}},{"id":"28b8c2c63fcd","number":105,"stem":20,"statement":"O desenvolvimento dirigido por testes (TDD) é modelado em três estados: vermelho, verde e refatorar. Um exemplo da ação de refatoração é a simulação do comportamento dos componentes que interagem com a unidade de teste que está falhando.","answer":"E","source":{"slug":"INPI_23","ano":2023},"explanation":{"verdict_reason":"Os três estados citados estão corretos, mas o exemplo não é de refatoração. Simular o comportamento das dependências que interagem com a unidade sob teste é usar dublês, mocks e stubs, o que pertence à construção do teste. Refatorar é melhorar a estrutura interna do código já aprovado, sem alterar seu comportamento externo.","distortion_type":"troca_de_termo","distorted_span":"a simulação do comportamento dos componentes que interagem com a unidade de teste que está falhando","corrected_statement":"O desenvolvimento dirigido por testes (TDD) é modelado em três estados: vermelho, verde e refatorar. Um exemplo da ação de refatoração é a eliminação de código duplicado sem alteração do comportamento externo.","concept":"Refatorar × simular dependências: melhorar estrutura × usar dublês de teste","citation":null,"trap_note":"A fase refatorar só começa com o teste verde. Qualquer ação descrita para fazer um teste que falha passar a rodar pertence às fases anteriores, não à refatoração."}},{"id":"75a59c30453b","number":118,"stem":21,"statement":"Considere-se o seguinte cenário, relativo ao índice de álcool encontrado no sangue de um motorista: normal, para índice inferior a 0,06%; multa, para índice entre 0,06% e 0,33%; crime, para índice superior a 0,33%. Nesse cenário, serão necessários, no mínimo, três casos de teste a fim de se atingir 100% de cobertura da análise do valor-limite de um programa desenvolvido para avaliar o referido índice.","answer":"E","source":{"slug":"INPI_23","ano":2023},"explanation":{"verdict_reason":"O cenário tem três faixas, mas duas fronteiras: 0,06 e 0,33. A análise do valor limite exige, em cada fronteira, o valor exatamente no limite e o valor imediatamente fora dele, o que leva a no mínimo quatro casos. Três casos bastariam para o particionamento de equivalência, que testa um representante por faixa, e é essa técnica que o item descreve sob o nome de valor limite.","distortion_type":"numero_errado","distorted_span":"três casos de teste","corrected_statement":"Nesse cenário, serão necessários, no mínimo, quatro casos de teste a fim de se atingir 100% de cobertura da análise do valor-limite de um programa desenvolvido para avaliar o referido índice.","concept":"Valor limite conta fronteiras, não faixas","citation":null,"trap_note":"Conte o que a técnica pede: particionamento conta faixas, valor limite conta fronteiras e multiplica por dois, pelo menos. Com n faixas contíguas há n-1 fronteiras."}},{"id":"584dd5427ad9","number":120,"stem":21,"statement":"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.","answer":"C","source":{"slug":"INPI_23","ano":2023},"explanation":{"verdict_reason":"A suíte de regressão não reexecuta todos os casos já escritos, o que seria inviável a cada mudança. Ela é projetada por amostragem: para cada função principal do software, selecionam-se os casos que representam as classes de erro relevantes daquela função, mais os casos das partes provavelmente afetadas pela alteração.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Regressão é suíte selecionada por classes de erro, não reexecução total","citation":null,"trap_note":"Regressão bem projetada é amostra representativa. Item que exija reexecutar tudo, ou que dispense reexecutar qualquer coisa, erra nos dois extremos."}},{"id":"969b4d4789ef","number":66,"stem":22,"statement":"Uma das fases do TDD (test driven development) é a refatoração do código, que tem o objetivo de melhorar a extensibilidade do código.","answer":"C","source":{"slug":"PGE_RJ_22","ano":2022},"explanation":{"verdict_reason":"Refatorar é a terceira fase do ciclo do TDD, depois de vermelho e verde. Com o teste passando, o código é reorganizado para melhorar sua estrutura interna, e é isso que preserva a capacidade de estendê-lo sem reescrevê-lo. O comportamento externo permanece o mesmo, garantido pela suíte que acabou de passar.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Refatoração como terceira fase do TDD","citation":null,"trap_note":"Refatoração dentro do TDD é fase, fora do TDD é técnica autônoma. Em ambos os casos a definição é a mesma: muda estrutura, preserva comportamento."}},{"id":"b72cf8ec7406","number":75,"stem":23,"statement":"No desenvolvimento guiado por testes (TDD), utiliza-se uma linguagem derivada do domínio do negócio para a definição dos casos de testes, ao passo que, no desenvolvimento orientado por comportamento (BDD), prioriza-se uma linguagem de programação que apoie a correção na implementação dos cenários de uso.","answer":"E","source":{"slug":"BANCO_DO_NORDESTE_22","ano":2022},"explanation":{"verdict_reason":"As duas metades estão trocadas. É o BDD que adota a linguagem derivada do domínio do negócio, escrevendo cenários legíveis pelo cliente com given, when e then. O TDD opera dentro da linguagem de programação, com testes escritos pelo desenvolvedor para guiar a implementação.","distortion_type":"inversao","distorted_span":"utiliza-se uma linguagem derivada do domínio do negócio para a definição dos casos de testes","corrected_statement":"No desenvolvimento orientado por comportamento (BDD), utiliza-se uma linguagem derivada do domínio do negócio para a definição dos casos de testes, ao passo que, no desenvolvimento guiado por testes (TDD), prioriza-se uma linguagem de programação que apoie a correção na implementação dos cenários de uso.","concept":"BDD fala a linguagem do negócio; TDD, a linguagem de programação","citation":null,"trap_note":"Quando o item apresenta dois conceitos em paralelo com ao passo que, a suspeita padrão é inversão. Monte o par certo antes de ler e confira lado a lado."}},{"id":"fbf92b4d9675","number":75,"stem":24,"statement":"O TDD (test-driven development), como atividade da XP, é uma forma disciplinada de organizar o código, alterando-o de modo a aprimorar sua estrutura interna, sem que se altere o comportamento externo do software.","answer":"E","source":{"slug":"BANRISUL_22","ano":2022},"explanation":{"verdict_reason":"Alterar a estrutura interna do código sem mudar seu comportamento externo é a definição de refatoração, não de TDD. O TDD é o ciclo de escrever o teste que falha, fazer passar e só então refatorar: a refatoração é uma das três fases, e não o nome do todo. A descrição está correta; o rótulo é que foi trocado.","distortion_type":"troca_de_termo","distorted_span":"O TDD (test-driven development)","corrected_statement":"A refatoração, como atividade da XP, é uma forma disciplinada de organizar o código, alterando-o de modo a aprimorar sua estrutura interna, sem que se altere o comportamento externo do software.","concept":"Refatoração × TDD: melhorar estrutura sem mudar comportamento × ciclo teste-código-refatoração","citation":null,"trap_note":"A frase sem alterar o comportamento externo é a impressão digital da refatoração. Onde ela aparecer com outro nome colado, o item trocou a etiqueta."}},{"id":"570fad623cb6","number":76,"stem":23,"statement":"Durante um projeto de um software, caso haja algum eventual atraso no desenvolvimento do produto, a solução com efeitos mais imediatos será a contratação, com urgência, de mais programadores, a fim de que o cronograma de execução do projeto mantenha-se em dia.","answer":"E","source":{"slug":"BANCO_DO_NORDESTE_22","ano":2022},"explanation":{"verdict_reason":"Acrescentar programadores a um projeto de software já atrasado tende a atrasá-lo ainda mais, e não a recuperá-lo: os novos precisam ser treinados pelos que estão produzindo, e o número de canais de comunicação cresce mais rápido que o número de pessoas. O efeito imediato descrito no item é o contrário do efeito real.","distortion_type":"relacao_causal","distorted_span":"a solução com efeitos mais imediatos será a contratação, com urgência, de mais programadores","corrected_statement":"Durante um projeto de um software, caso haja algum eventual atraso no desenvolvimento do produto, a contratação, com urgência, de mais programadores tende a atrasar ainda mais o projeto, razão pela qual costuma ser preferível renegociar escopo ou prazo.","concept":"Lei de Brooks: mais gente em projeto atrasado atrasa mais","citation":null,"trap_note":"Esforço humano em software não é intercambiável com tempo. Item que trate pessoa-mês como grandeza divisível, ou que prometa recuperar cronograma por contratação, está invertendo a relação conhecida."}},{"id":"23f47395b445","number":84,"stem":25,"statement":"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.","answer":"C","source":{"slug":"BANCO_DO_NORDESTE_22","ano":2022},"explanation":{"verdict_reason":"O teste baseado em diretriz seleciona casos a partir de listas de erros que os programadores cometem com frequência, como tratar coleção vazia, estourar limite de vetor, dividir por zero ou usar ponteiro nulo. É uma estratégia eficaz porque aponta o esforço para onde o histórico mostra que os defeitos se concentram.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Teste baseado em diretriz: casos derivados de erros comuns conhecidos","citation":null,"trap_note":"No nível de unidade há três estratégias de seleção que a prova cita: partição de equivalência, valor limite e diretriz baseada em erros comuns. As três derivam de conhecimento prévio, não de sorteio."}},{"id":"c69797a15f2b","number":85,"stem":25,"statement":"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.","answer":"C","source":{"slug":"BANCO_DO_NORDESTE_22","ano":2022},"explanation":{"verdict_reason":"Um caso de uso descreve uma interação completa que atravessa vários componentes do sistema, e o diagrama de sequência correspondente mostra quais objetos colaboram e em que ordem. Exatamente por isso ele serve de base para o teste de integração: exercitar o caso de uso obriga os componentes envolvidos a interagir pelas interfaces reais.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Casos de uso como base para o teste de integração","citation":null,"trap_note":"Caso de uso é a ponte entre requisito e teste: no nível de integração ele define o percurso entre componentes; no de aceitação, o critério de pronto para o usuário."}},{"id":"03fe12fc5fdb","number":86,"stem":26,"statement":"A metodologia empregada nos testes de caixa branca tem como base a geração de casos de teste por meio do conhecimento da estrutura interna do programa.\n\n<html>\n  <p id=“saida”></p>\n  <head>\n    <script type=“text/javascript” >\n       const user = {\n       nome: 'Pedro Maria',\n       email: 'pedro.maria@gmail.com',\n       idade: 25,\n       nascimento: '21/02/1996',\n       masculino: true\n    };\n    document.getElementById(“saida”).\n       innerHTML = ““;\n    for (const key in user) {\n       document.getElementById(“saida”).\n       InnerHTML += `$ {key}:\n       $ {user[key]}`;\n    }\n    </script>\n  </head>\n</html>","answer":"C","source":{"slug":"FUB_22","ano":2022},"explanation":{"verdict_reason":"A técnica de caixa-branca, ou estrutural, gera os casos de teste a partir do conhecimento da estrutura interna do programa: os caminhos do fluxo de controle, as condições das decisões, os laços e o fluxo de dados. O insumo é o código, não a especificação.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Caixa-branca deriva casos da estrutura interna do programa","citation":null,"trap_note":"Em segurança, o mesmo par muda de figurino: no teste de invasão de caixa-branca a equipe recebe informação completa do ambiente, e no de caixa-preta não recebe nada."}},{"id":"9277b15fb4ac","number":86,"stem":25,"statement":"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.","answer":"E","source":{"slug":"BANCO_DO_NORDESTE_22","ano":2022},"explanation":{"verdict_reason":"Interface que muda muito e rápido é o pior cenário para automação: cada mudança quebra os scripts, e o custo de manter a suíte supera o de executar o teste à mão. A automação compensa no que é estável e repetido. Com a automação ainda indisponível e a interface instável, o teste manual é o mais apropriado.","distortion_type":"inversao","distorted_span":"O teste automatizado usualmente é mais apropriado que o teste manual","corrected_statement":"O teste manual usualmente é mais apropriado que o teste automatizado 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.","concept":"Automação compensa no estável e repetitivo, não no volátil","citation":null,"trap_note":"Automatizado não é sinônimo de melhor. O critério é custo de manutenção do script contra número de execuções: muita mudança e poucas execuções favorecem o manual."}},{"id":"611ceecbcf45","number":99,"stem":27,"statement":"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.","answer":"C","source":{"slug":"BANRISUL_22","ano":2022},"explanation":{"verdict_reason":"O item enuncia os dois objetivos de um caso de teste eficaz, que são complementares: mostrar que o componente cumpre o que promete quando usado como esperado, e revelar os defeitos existentes quando eles existem. Um caso que só confirma o caminho feliz cumpre metade da função.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Caso de teste eficaz: demonstra o esperado e revela defeitos","citation":null,"trap_note":"Teste bem-sucedido, na literatura, é o que encontra defeito, não o que passa. Guarde essa definição, porque ela sustenta vários itens de conceito geral."}},{"id":"9d0df07b193e","number":100,"stem":27,"statement":"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.","answer":"E","source":{"slug":"BANRISUL_22","ano":2022},"explanation":{"verdict_reason":"No teste de classes de objeto, a recomendação é o oposto: testar todas as operações associadas ao objeto, atribuir e consultar todos os atributos e exercitar o objeto em todos os seus estados possíveis, o que exige simular todos os eventos que provocam mudança de estado. Um evento não simulado é uma transição não testada.","distortion_type":"inversao","distorted_span":"não havendo necessidade de simular todos os eventos que causam mudança de estado","corrected_statement":"Ao se testarem as classes do objeto, devem-se testar todas as operações a ele associadas, sendo necessário simular todos os eventos que causam mudança de estado.","concept":"Teste de classe: todas as operações, todos os atributos, todos os estados","citation":null,"trap_note":"Quando o item dispensa uma exigência de cobertura, desconfie. A banca costuma transformar em opcional aquilo que a literatura lista como obrigatório, e vice-versa."}},{"id":"47113826b7c2","number":101,"stem":27,"statement":"O teste unitário é o processo de testar os componentes de programa, como métodos ou classes de objeto.","answer":"C","source":{"slug":"BANRISUL_22","ano":2022},"explanation":{"verdict_reason":"Teste de unidade é o teste do menor elemento com comportamento próprio dentro do programa. Em software orientado a objetos, essas unidades são os métodos e as classes de objeto, testados isoladamente das demais partes do sistema.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Unidade: métodos e classes de objeto","citation":null,"trap_note":"Unidade é o componente individual; o agrupamento de componentes com interface própria é o nível de componente; a combinação de subsistemas é integração."}},{"id":"65bcb9368d0d","number":61,"stem":28,"statement":"Durante o desenvolvimento do sistema, os testes podem ocorrer no nível de componentes e no nível unitário: no primeiro caso, o foco é testar as interfaces dos componentes; no segundo, o foco é testar a funcionalidade dos métodos.","answer":"C","source":{"slug":"PETROBRAS_21_NS","ano":2021},"explanation":{"verdict_reason":"São dois níveis distintos e o item os descreve na posição certa. O teste de unidade exercita o menor elemento com comportamento próprio, isto é, a funcionalidade dos métodos. O teste de componente trata o componente como um agrupamento já montado e concentra-se nas suas interfaces, que é por onde os outros o utilizam.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Unidade testa métodos; componente testa interfaces do componente","citation":null,"trap_note":"A escala é contínua: método, componente, subsistemas integrados, sistema, aceitação. O que muda a cada degrau é o tamanho do que se monta e o tipo de defeito que se procura."}},{"id":"9c4b16c342a4","number":69,"stem":29,"statement":"No teste de unidade de um software, diante da presença de uma classe geral com especializações, é preciso testar um método definido na superclasse em cada uma de suas subclasses.","answer":"C","source":{"slug":"SEFAZ_CE_21","ano":2021},"explanation":{"verdict_reason":"Em orientação a objetos, um método herdado executa em um contexto diferente em cada subclasse: os atributos, as sobrescritas e os invariantes da subclasse mudam o comportamento efetivo. Por isso o teste do método na superclasse não transfere automaticamente para as especializações, e ele precisa ser reexecutado no contexto de cada subclasse.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Herança exige reteste do método herdado em cada subclasse","citation":null,"trap_note":"Herança não herda a confiança do teste. O mesmo raciocínio vale para polimorfismo: cada ligação dinâmica possível é um caminho a exercitar."}},{"id":"7e110433c67d","number":72,"stem":30,"statement":"Em TDD, os testes de um sistema devem ocorrer antes da implementação e ser oportunos, isolados e autoverificáveis.","answer":"C","source":{"slug":"SERPRO_21","ano":2021},"explanation":{"verdict_reason":"O item reúne a regra de ordem do TDD com três dos princípios FIRST. Oportunos corresponde ao timely: o teste é escrito pouco antes do código de produção. Isolados corresponde ao independent, e autoverificáveis ao self-validating, que exige que o próprio teste diga se passou ou falhou, sem inspeção humana do resultado.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"TDD e princípios FIRST: rápido, isolado, repetível, autoverificável, oportuno","citation":null,"trap_note":"FIRST tem cinco letras e cinco princípios: fast, independent, repeatable, self-validating, timely. Guarde a lista fechada, porque a banca gosta de inserir um sexto adjetivo inventado."}},{"id":"9a872c64dd43","number":81,"stem":31,"statement":"Um dos objetivos do teste caixa-preta é identificar erros em interfaces, em estruturas de dados e em desempenho.","answer":"C","source":{"slug":"PETROBRAS_21_NS","ano":2021},"explanation":{"verdict_reason":"O teste de caixa-preta procura, entre outras categorias, funções incorretas ou ausentes, erros de interface, erros em estruturas de dados ou no acesso a bases externas, erros de comportamento ou desempenho e erros de inicialização e término. Interfaces, estruturas de dados e desempenho estão na lista porque se manifestam no comportamento externo do software.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Categorias de erro buscadas pelo teste caixa-preta","citation":null,"trap_note":"Caixa-preta não significa só entrada e saída de função. Como ela observa o software de fora, alcança desempenho e interface, que são atributos observáveis sem ler o código."}},{"id":"604d0ba560ad","number":87,"stem":32,"statement":"Teste fumaça é uma abordagem de teste de integração usada à medida que os produtos de software são desenvolvidos; esse teste permite à equipe realizar a verificação no software frequentemente, conforme novos componentes são a ele acrescentados.","answer":"C","source":{"slug":"PETROBRAS_21_NS","ano":2021},"explanation":{"verdict_reason":"O teste de fumaça é uma abordagem de integração aplicada durante o desenvolvimento: os componentes prontos são integrados em um build e submetidos a um conjunto rápido de testes que confirma se as funções principais sobem e funcionam. Como é barato e rápido, pode ser repetido com frequência, a cada novo componente acrescentado.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Teste de fumaça: verificação rápida e frequente do build integrado","citation":null,"trap_note":"Fumaça responde se vale a pena continuar testando. Se o build não passa no fumaça, os testes mais caros nem são executados."}},{"id":"a3740285a76a","number":89,"stem":33,"statement":"Para a validação dos requisitos especificados, é uma decisão válida gerar casos de testes, a partir dos requisitos de usuário, antes do início da codificação das funcionalidades.","answer":"C","source":{"slug":"SERPRO_21","ano":2021},"explanation":{"verdict_reason":"Casos de teste derivados dos requisitos de usuário podem ser escritos assim que os requisitos existem, antes de qualquer código. Escrevê-los cedo cumpre duas funções: valida a própria especificação, expondo requisito ambíguo ou incompleto quando alguém tenta transformá-lo em caso concreto, e deixa pronto o critério de aceitação da funcionalidade.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Casos de teste derivados dos requisitos antes da codificação","citation":null,"trap_note":"É o mesmo princípio do TDD, só que no nível dos requisitos: o teste escrito antes funciona como especificação executável. Item que proíba escrever teste antes do código está errado nos dois níveis."}},{"id":"95506d1055e6","number":90,"stem":33,"statement":"O uso de técnicas do tipo caixa-preta é adequado para avaliar a qualidade do atendimento aos requisitos não funcionais, como, por exemplo, o comportamento do sistema em relação a valores-limite.","answer":"C","source":{"slug":"SERPRO_21","ano":2021},"explanation":{"verdict_reason":"A técnica de caixa-preta avalia o software pelo lado de fora, a partir da especificação e do comportamento observável, sem conhecer a estrutura interna. É por isso que ela serve aos requisitos não funcionais, que se manifestam justamente na fronteira externa: desempenho, compatibilidade, comportamento em valores-limite. Os valores-limite são derivados do que a especificação define, não do código.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Caixa-preta também cobre requisitos não funcionais","citation":null,"trap_note":"Não reduza caixa-preta a teste de função. O critério é a fonte dos casos: especificação e comportamento externo é caixa-preta; estrutura interna, caminhos e condições é caixa-branca."}},{"id":"ca5dda0c0268","number":91,"stem":32,"statement":"Os processos de verificação e validação de um sistema devem demonstrar que ele atende à sua especificação e que o seu comportamento suporta os requisitos do cliente, por meio da busca de erros na especificação ou de projeto.","answer":"C","source":{"slug":"PETROBRAS_21_NS","ano":2021},"explanation":{"verdict_reason":"Verificação e validação formam um processo único com duas demonstrações distintas: que o sistema atende à sua especificação, o lado da verificação, e que seu comportamento sustenta os requisitos do cliente, o lado da validação. Ambas operam pela descoberta de erros, que podem estar tanto na implementação quanto na própria especificação ou no projeto.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"V&V: conformidade com a especificação e atendimento ao cliente","citation":null,"trap_note":"Erro de especificação existe e é o mais caro. É por isso que a validação não pode ser substituída pela verificação: implementar perfeitamente a especificação errada passa em toda a verificação."}},{"id":"0310462e992c","number":95,"stem":34,"statement":"No caso de um programa que considere como válidas as idades entre 21 e 75 anos completos de vida, incluindo esses limites, o conjunto mínimo de valores suficientes para a realização de um teste de unidade que cubra todas as partições de entrada é 21, 48 e 75.","answer":"E","source":{"slug":"SERPRO_21","ano":2021},"explanation":{"verdict_reason":"Um intervalo válido de 21 a 75 anos produz três partições de entrada: abaixo de 21, entre 21 e 75, acima de 75. O conjunto proposto usa três valores, mas todos dentro da mesma partição válida, deixando as duas partições inválidas sem nenhum caso. Três casos bastam, desde que um deles fique abaixo do mínimo e outro acima do máximo.","distortion_type":"numero_errado","distorted_span":"21, 48 e 75","corrected_statement":"No caso de um programa que considere como válidas as idades entre 21 e 75 anos completos de vida, incluindo esses limites, o conjunto mínimo de valores suficientes para a realização de um teste de unidade que cubra todas as partições de entrada é 20, 48 e 76.","concept":"Cobertura de partições exige um valor em cada classe, inclusive nas inválidas","citation":null,"trap_note":"Em item de contagem, conte as partições antes de olhar os números oferecidos. Três valores na mesma faixa não cobrem três faixas, por mais que a quantidade bata."}},{"id":"11b558feb852","number":96,"stem":34,"statement":"Realizado o teste unitário de um módulo, o teste de integração contribuirá para a avaliação da existência de erros associados às interfaces do sistema.","answer":"C","source":{"slug":"SERPRO_21","ano":2021},"explanation":{"verdict_reason":"O teste de unidade ataca o defeito dentro do módulo; com os módulos já validados isoladamente, o que resta são os erros que só aparecem quando eles se combinam. É exatamente isso que o teste de integração avalia: parâmetros trocados, contratos mal entendidos, suposições incompatíveis nas interfaces entre componentes.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Integração revela erros de interface entre módulos já testados","citation":null,"trap_note":"A sequência unidade e depois integração não é burocracia: sem a unidade testada, o defeito encontrado na integração pode estar dentro do módulo, e a equipe perde tempo procurando na interface."}},{"id":"7b98eb880ed3","number":97,"stem":34,"statement":"Uma revisão por pares de um software avalia os modelos adotados na programação e os erros constantes no código, o que exige que o programa seja colocado em condições de execução próximas ao ambiente real de operação.","answer":"E","source":{"slug":"SERPRO_21","ano":2021},"explanation":{"verdict_reason":"Revisão por pares é técnica de verificação estática: examina-se o artefato, modelos e código-fonte, sem executá-lo. É essa a razão de ela poder ser aplicada cedo e barato, antes de existir ambiente montado. Exigir execução em condições próximas às reais é requisito de teste dinâmico, notadamente do teste de sistema.","distortion_type":"atribuicao_errada","distorted_span":"o que exige que o programa seja colocado em condições de execução próximas ao ambiente real de operação","corrected_statement":"Uma revisão por pares de um software avalia os modelos adotados na programação e os erros constantes no código, o que não exige que o programa seja colocado em condições de execução.","concept":"Revisão por pares é teste estático: não executa o programa","citation":null,"trap_note":"Estático × dinâmico é a primeira divisão do tópico. Revisão, inspeção, walkthrough e análise estática não executam nada; teste de unidade, integração, sistema e aceitação executam."}},{"id":"47e672e44a02","number":100,"stem":35,"statement":"No teste de penetração de caixa branca não são fornecidas informações prévias à equipe de testadores sobre a infraestrutura de segurança da organização; por isso, vulnerabilidades eventualmente existentes e não descobertas no tempo alocado para o teste poderão permanecer ativas no ambiente.","answer":"E","source":{"slug":"PETROBRAS_21_NS","ano":2021},"explanation":{"verdict_reason":"O par está invertido. No teste de invasão de caixa-preta a equipe não recebe informação prévia sobre o ambiente e precisa descobrir tudo, o que limita o alcance no tempo disponível. No de caixa-branca ela recebe topologia, código, configurações e credenciais, o que aumenta a cobertura justamente por dispensar a fase de descoberta.","distortion_type":"troca_de_termo","distorted_span":"No teste de penetração de caixa branca não são fornecidas informações prévias à equipe de testadores","corrected_statement":"No teste de penetração de caixa preta não são fornecidas informações prévias à equipe de testadores sobre a infraestrutura de segurança da organização; por isso, vulnerabilidades eventualmente existentes e não descobertas no tempo alocado para o teste poderão permanecer ativas no ambiente.","concept":"Pentest: caixa-preta sem informação prévia, caixa-branca com informação completa","citation":null,"trap_note":"A metáfora é a mesma do teste funcional: branca enxerga o interior, preta não enxerga. Caixa-cinza é o meio-termo, com informação parcial."}},{"id":"33d50f272141","number":51,"stem":36,"statement":"Na definição de métodos de teste em JUnit, a anotação @BeforeClass pode ser usada em métodos que implementem atividades que consomem muito tempo.","answer":"C","source":{"slug":"DPDF_20_ANALISTA","ano":2020},"explanation":{"verdict_reason":"O método anotado com BeforeClass é executado uma única vez, antes de todos os testes da classe, e não a cada método. Por isso é o lugar indicado para preparações caras, como abrir conexão com banco, carregar massa de dados ou iniciar um servidor, cujo custo seria multiplicado se repetido em cada teste.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"BeforeClass: preparação única e custosa por classe de teste","citation":null,"trap_note":"Separe o ciclo de vida: Before roda antes de cada teste, BeforeClass uma vez por classe. Item que troque a frequência das duas anotações é troca de termo clássica em JUnit."}},{"id":"c8c09c3f5b0e","number":58,"stem":37,"statement":"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.","answer":"C","source":{"slug":"STJ_18","ano":2018},"explanation":{"verdict_reason":"A definição clássica de teste é dinâmica e comparativa: executa-se o programa ou sistema com a intenção de confrontar seu comportamento observado com o que a especificação de requisitos previa. Execução mais critério de comparação são os dois elementos essenciais, e ambos estão no item.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Teste: execução do programa para confronto com a especificação","citation":null,"trap_note":"Sem oráculo não há teste: é preciso saber de antemão qual é o resultado esperado. Essa é a razão de o teste autovalidável ser princípio, e não luxo."}},{"id":"d6d10a902654","number":59,"stem":37,"statement":"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.","answer":"E","source":{"slug":"STJ_18","ano":2018},"explanation":{"verdict_reason":"As duas metades estão trocadas. O teste de unidade é o que dá retorno sobre a qualidade interna, porque escrever o teste expõe acoplamento, responsabilidades mal divididas e dificuldade de isolar o módulo, orientando o projeto do código. O teste de aceitação olha o sistema de fora e informa sobre a qualidade externa, a percebida pelo usuário.","distortion_type":"inversao","distorted_span":"os testes de unidade propiciam a qualidade externa","corrected_statement":"Enquanto os testes de aceitação propiciam a qualidade externa, os testes de unidade 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.","concept":"Unidade informa qualidade interna; aceitação, qualidade externa","citation":null,"trap_note":"Interna é o que o desenvolvedor vê, o projeto do código; externa é o que o usuário vê, o comportamento. O nível mais interno de teste fala da qualidade interna, e o mais externo, da externa."}},{"id":"22aa75b0267d","number":60,"stem":37,"statement":"No método de desenvolvimento TDD (test driven development), o desenvolvedor escreve primeiro um caso de teste e, posteriormente, o código.","answer":"C","source":{"slug":"STJ_18","ano":2018},"explanation":{"verdict_reason":"É a ordem que define o método: o desenvolvedor escreve primeiro o caso de teste, que falha porque a funcionalidade ainda não existe, e só então escreve o código que o faz passar. O teste funciona como especificação executável daquilo que será implementado.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"TDD: primeiro o caso de teste, depois o código","citation":null,"trap_note":"Este item se repete quase sem variação em vários concursos. Basta localizar a ordem afirmada, porque é sempre ela que decide."}},{"id":"81db7a27790c","number":81,"stem":38,"statement":"Situação hipotética: Ao se iniciar a especificação de requisitos de um software para controlar o gasto de folhas impressas de um setor, o analista de requisitos, juntamente com o gestor, definiu um cenário de teste em que, ao se comandar a impressão, a chave do usuário autenticado no sistema que comandar uma impressão acionará o contador de impressões do setor de locação desse usuário. Assertiva: Nessa situação, o teste validará o cenário do requisito definido junto com o gestor.","answer":"C","source":{"slug":"MP_PI_18","ano":2018},"explanation":{"verdict_reason":"O cenário de teste foi definido junto com o gestor, que é quem representa a necessidade real do setor. Executar esse cenário confronta o software com aquela necessidade acordada, e isso é validação, e não simples verificação interna contra um documento técnico.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Validação: confronto do software com a necessidade acordada com o cliente","citation":null,"trap_note":"Quando o item mencionar participação do cliente, do gestor ou do usuário na definição do cenário, a palavra que fecha é validação. Verificação é o confronto com a especificação, feito pela equipe."}},{"id":"fcc447a93705","number":95,"stem":39,"statement":"Na verificação de software, busca-se identificar se o software está sendo construído corretamente, ou seja, se ele está de acordo com a especificação.","answer":"C","source":{"slug":"FUB_18","ano":2018},"explanation":{"verdict_reason":"Verificação responde à pergunta estamos construindo o produto corretamente, e o padrão de comparação é a especificação. Validação responde à pergunta estamos construindo o produto certo, e o padrão de comparação é a necessidade real do cliente. O item enuncia a verificação com o padrão correto.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Verificação: conformidade com a especificação","citation":null,"trap_note":"Duas frases resolvem quase todo item do tópico: verificação é construir certo o produto, validação é construir o produto certo. Localize o padrão de comparação citado, especificação ou necessidade, e o rótulo se decide sozinho."}},{"id":"29511cb90a69","number":96,"stem":39,"statement":"Os testes de caixa-branca buscam verificar o comportamento interno do software, ou seja, os elementos relacionados ao código-fonte desse software.","answer":"C","source":{"slug":"FUB_18","ano":2018},"explanation":{"verdict_reason":"O teste de caixa-branca, também chamado estrutural, deriva os casos do conhecimento da implementação: comandos, decisões, condições, laços e caminhos do código-fonte. É o oposto do caixa-preta, que só enxerga entradas, saídas e a especificação.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Caixa-branca: comportamento interno e código-fonte","citation":null,"trap_note":"Branca vê o código, preta não vê. Todo critério de cobertura, de comando, de decisão, de condição ou de caminho, pertence obrigatoriamente à caixa-branca."}},{"id":"54699371a5c9","number":100,"stem":40,"statement":"Com EJB em uso na situação em que, no pool do contêiner, haja diversas instâncias de um bean sem estado de sessão, a invocação de um método por um cliente pode ser delegada a qualquer uma das instâncias.","answer":"C","source":{"slug":"STJ_18","ano":2018},"explanation":{"verdict_reason":"O bean de sessão sem estado não guarda estado conversacional entre chamadas de um mesmo cliente. Por isso todas as instâncias do pool são equivalentes, e o contêiner pode delegar a invocação a qualquer uma delas. É justamente essa intercambialidade que permite ao contêiner manter um pool e reaproveitar instâncias entre clientes.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Bean de sessão sem estado: instâncias intercambiáveis no pool","citation":null,"trap_note":"Sem estado permite pool e qualquer instância; com estado exige vincular a instância ao cliente durante a conversação. A mesma lógica vale para réplicas de serviço sem estado em qualquer arquitetura."}},{"id":"c103864f82f1","number":102,"stem":40,"statement":"Ao aplicar o desenvolvimento orientado a testes em um projeto desenvolvido em Java, é necessário incluir nos métodos elementos que possibilitem a captura dos dados durante o processo de testes.","answer":"E","source":{"slug":"STJ_18","ano":2018},"explanation":{"verdict_reason":"O desenvolvimento orientado a testes não exige alterar o código de produção para permitir a captura de dados durante os testes. O teste exercita o componente por sua interface pública, com as dependências substituídas por dublês, e o resultado é conferido por asserções dentro do próprio teste. Instrumentar os métodos para fins de teste contamina o código com responsabilidade que não é dele.","distortion_type":"generalizacao","distorted_span":"é necessário incluir nos métodos elementos que possibilitem a captura dos dados durante o processo de testes","corrected_statement":"Ao aplicar o desenvolvimento orientado a testes em um projeto desenvolvido em Java, não é necessário incluir nos métodos elementos que possibilitem a captura dos dados durante o processo de testes, pois o teste exercita a interface pública do componente.","concept":"TDD não exige instrumentar o código de produção","citation":null,"trap_note":"O que o TDD muda é a ordem de escrita, não a estrutura do código de produção. Item que imponha alteração no código para viabilizar o teste está inventando requisito."}},{"id":"1e770becaf70","number":103,"stem":40,"statement":"Em relação ao trecho de código a seguir, que implementa parte de uma lista encadeada em Java, o método m1, quando instanciado de forma correta, gera como resultado o somatório dos valores armazenados nos nós da lista encadeada.\n\npublic class Lista {\n   private Lista proxima;\n   private int elemento;\npublic int m1()\n   {\n     int x;\n     soma = this.elemento + this.proxima.m1();\n     return x;\n   }\n}","answer":"E","source":{"slug":"STJ_18","ano":2018},"explanation":{"verdict_reason":"O método não produz somatório algum. A variável x é declarada e nunca recebe valor, mas é ela que se retorna; o resultado da soma é atribuído a soma, que sequer foi declarada. Além disso, a recursão chama proxima.m1() sem condição de parada para o último nó, cuja referência é nula. O código nem sequer compila, e o comportamento afirmado não se realiza.","distortion_type":"atribuicao_errada","distorted_span":"gera como resultado o somatório dos valores armazenados nos nós da lista encadeada","corrected_statement":"Em relação ao trecho de código a seguir, que implementa parte de uma lista encadeada em Java, o método m1 não gera o somatório dos valores armazenados nos nós, pois retorna a variável x, que não foi inicializada, e atribui a soma a uma variável não declarada.","concept":"Código de soma recursiva sem variável declarada, sem retorno correto e sem caso base","citation":null,"trap_note":"Em item com trecho de código, confira três coisas antes de julgar a intenção: toda variável usada foi declarada, o que é retornado foi atribuído e a recursão tem condição de parada. A banca descreve o que o código deveria fazer, não o que ele faz."}},{"id":"6f23a19fb895","number":106,"stem":41,"statement":"Uma característica e limitação do JUnit é a impossibilidade de definição de parâmetros para construtores e métodos.","answer":"E","source":{"slug":"STJ_18","ano":2018},"explanation":{"verdict_reason":"O JUnit aceita parâmetros. Os testes parametrizados permitem executar o mesmo método de teste com vários conjuntos de valores, e os construtores de classes de teste parametrizadas recebem esses valores. A afirmação transforma em impossibilidade técnica um recurso que a ferramenta oferece.","distortion_type":"inversao","distorted_span":"a impossibilidade de definição de parâmetros para construtores e métodos","corrected_statement":"Uma característica do JUnit é a possibilidade de definição de parâmetros para construtores e métodos, por meio dos testes parametrizados.","concept":"JUnit suporta testes parametrizados","citation":null,"trap_note":"Desconfie de itens que atribuem limitações a ferramentas consolidadas. Impossibilidade, não permite e não suporta são formulações absolutas que raramente sobrevivem."}},{"id":"5041fdb9236f","number":106,"stem":42,"statement":"Apesar de ser um algoritmo criptográfico assimétrico voltado para chave pública, o RSA é considerado frágil sob o ponto de vista de troca de chaves em redes públicas, devido ao fato de não suportar cifra de bloco.","answer":"E","source":{"slug":"MP_PI_18","ano":2018},"explanation":{"verdict_reason":"O RSA é precisamente o algoritmo usado para resolver a troca de chaves em redes públicas: cifra-se a chave simétrica com a chave pública do destinatário, sem que nada secreto precise trafegar. Não suportar cifra de bloco não é defeito nem causa de fragilidade, porque o RSA é assimétrico e não foi projetado para cifrar grandes volumes de dados. A oração causal é inventada.","distortion_type":"relacao_causal","distorted_span":"devido ao fato de não suportar cifra de bloco","corrected_statement":"Por ser um algoritmo criptográfico assimétrico voltado para chave pública, o RSA é adequado à troca de chaves em redes públicas, pois permite cifrar a chave simétrica com a chave pública do destinatário.","concept":"RSA é assimétrico e serve exatamente ao transporte de chaves","citation":null,"trap_note":"Item que justifica uma fragilidade com uma característica irrelevante está usando a oração causal como disfarce. Pergunte se a causa citada tem qualquer relação com o efeito alegado."}},{"id":"af96cd6c3839","number":107,"stem":42,"statement":"O Hibernate é uma solução tecnológica para ORM (mapeamento objeto-relacional) que aceita o uso da JPA (Java Persistence API) e que permite padronizar as implementações de ORM em Java, embora ainda seja possível mapear as classes utilizando-se o XML.","answer":"C","source":{"slug":"MP_PI_18","ano":2018},"explanation":{"verdict_reason":"O Hibernate é uma implementação de mapeamento objeto-relacional que também funciona como provedor de JPA, a especificação que padroniza o ORM em Java. Aderir à JPA não elimina as formas próprias de configuração do Hibernate: o mapeamento continua podendo ser declarado por anotações ou por arquivos XML.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Hibernate implementa JPA e aceita mapeamento por anotação ou XML","citation":null,"trap_note":"JPA é a especificação, Hibernate é a implementação. A relação especificação e implementação é a mesma de JDBC e driver, e a banca costuma inverter os dois lados."}},{"id":"d07a284de711","number":60,"stem":43,"statement":"O TDD (test driven development) parte de um caso de teste que caracteriza uma melhoria desejada ou nova funcionalidade a ser desenvolvida, de modo a confirmar o comportamento correto e possibilitar a evolução ou refatoração do código.","answer":"C","source":{"slug":"STM_17_ANALISTA_TECNICO","ano":2017},"explanation":{"verdict_reason":"O ciclo do TDD começa por um caso de teste que expressa a melhoria ou a nova funcionalidade desejada e que, por isso, falha de início. O código é escrito para fazê-lo passar, e a suíte acumulada é o que permite refatorar depois com segurança, porque qualquer quebra de comportamento aparece imediatamente.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"TDD: teste como ponto de partida e rede de proteção da refatoração","citation":null,"trap_note":"A refatoração depende do teste, e não o contrário. Sem suíte automatizada não há como garantir que a mudança de estrutura preservou o comportamento externo."}},{"id":"ace62232df6c","number":68,"stem":44,"statement":"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.","answer":"E","source":{"slug":"STM_17_ANALISTA_TECNICO","ano":2017},"explanation":{"verdict_reason":"O teste de regressão reexecuta casos já existentes para confirmar que uma alteração não quebrou o que antes funcionava. Aumentar a carga até o sistema falhar é o propósito do teste de estresse. O trocadilho com regredir a carga disfarça a substituição de uma definição pela outra.","distortion_type":"troca_de_termo","distorted_span":"verificar se o sistema pode operar na carga necessária","corrected_statement":"Testes de regressão servem ao propósito de verificar se as alterações feitas no sistema introduziram defeitos em funcionalidades que antes operavam corretamente.","concept":"Regressão × estresse: efeito colateral de mudança × limite de carga","citation":null,"trap_note":"Regressão tem a ver com mudança no software, não com variação de carga. Sempre que a frase falar em aumentar carga, o nome certo está no grupo carga, estresse ou desempenho."}},{"id":"2dac3166a301","number":69,"stem":44,"statement":"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.","answer":"C","source":{"slug":"STM_17_ANALISTA_TECNICO","ano":2017},"explanation":{"verdict_reason":"O escopo do teste de sistema acompanha o processo de desenvolvimento. No modelo em cascata, o sistema é integrado uma vez e testado por inteiro ao final. No desenvolvimento iterativo, cada ciclo entrega um incremento, e o teste de sistema daquela iteração recai sobre o incremento a ser entregue ao cliente.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Escopo do teste de sistema em cascata × iterativo","citation":null,"trap_note":"O nível do teste não muda de nome com o processo, muda de escopo. Essa é a razão de a regressão ser vital no iterativo: o incremento novo pode quebrar os anteriores."}},{"id":"47109970dbb6","number":70,"stem":44,"statement":"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.","answer":"C","source":{"slug":"STM_17_ANALISTA_TECNICO","ano":2017},"explanation":{"verdict_reason":"Na integração bottom-up parte-se dos componentes de infraestrutura, que prestam serviços comuns às demais camadas, e sobre eles vão sendo acrescentados os componentes funcionais. Como uma característica do sistema costuma atravessar várias camadas, testá-la pode exigir integrar componentes de origens diferentes.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Integração bottom-up: da infraestrutura para as funcionalidades","citation":null,"trap_note":"Bottom-up sobe da infraestrutura e precisa de drivers; top-down desce da camada de mais alto nível e precisa de stubs. Quem precisa de stub é o top-down."}},{"id":"f1bfb42d7025","number":103,"stem":45,"statement":"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.","answer":"C","source":{"slug":"PREF_JP_17_CGM","ano":2017},"explanation":{"verdict_reason":"O particionamento de equivalência é técnica funcional, de caixa-preta, porque deriva os casos da especificação do módulo e não do seu código. O procedimento é dividir o domínio de entrada em classes cujos elementos devem ser tratados de forma equivalente e extrair um caso representativo de cada classe.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Particionamento de equivalência é técnica de caixa-preta","citation":null,"trap_note":"Classifique cada técnica pelo insumo: quem parte da especificação é caixa-preta, quem parte do código é caixa-branca. Particionamento e valor limite são sempre caixa-preta."}},{"id":"c68a5fa2be21","number":51,"stem":46,"statement":"As novas versões de um software passam pelos testes realizados pela equipe de desenvolvimento de sistema, que valida o uso do software e o libera para utilização pelo usuário final.","answer":"E","source":{"slug":"FUNPRESP_16_JUD","ano":2016},"explanation":{"verdict_reason":"Validar o uso do software e liberá-lo para o usuário final é o papel do teste de aceitação, conduzido pelo cliente ou usuário, não pela equipe de desenvolvimento. A equipe faz verificação: testa contra a especificação, nos níveis de unidade, integração e sistema. Quem confirma que o produto é o que se precisava é quem tem a necessidade.","distortion_type":"atribuicao_errada","distorted_span":"que valida o uso do software e o libera para utilização pelo usuário final","corrected_statement":"As novas versões de um software passam pelos testes realizados pela equipe de desenvolvimento de sistema, cabendo ao usuário, no teste de aceitação, validar o uso do software e liberá-lo para utilização.","concept":"Aceitação é validação e cabe ao cliente, não à equipe de desenvolvimento","citation":null,"trap_note":"Identifique sempre o ator: equipe de desenvolvimento verifica, usuário valida. Item que dê à equipe a palavra final sobre a liberação trocou o responsável."}},{"id":"ce0281f1a824","number":52,"stem":46,"statement":"O teste de regressão visa garantir a integridade de um software já testado que tenha recebido uma nova implementação.","answer":"C","source":{"slug":"FUNPRESP_16_JUD","ano":2016},"explanation":{"verdict_reason":"Toda alteração em software já testado pode quebrar comportamento que antes funcionava, por efeito colateral em código compartilhado ou em suposições implícitas. O teste de regressão reexecuta os casos existentes justamente para confirmar que a integridade do que já estava validado foi preservada depois da nova implementação.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Regressão preserva a integridade do que já funcionava","citation":null,"trap_note":"Regressão é definida pela causa, que é a mudança no software, e não pelo nível em que ocorre. Existe regressão de unidade, de integração e de sistema."}},{"id":"d10f717d5bf7","number":53,"stem":46,"statement":"Na realização do teste de integração, a equipe de testes busca a origem de um problema detectado e procura identificar os componentes a serem depurados.","answer":"C","source":{"slug":"FUNPRESP_16_JUD","ano":2016},"explanation":{"verdict_reason":"Quando um defeito aparece na integração, ele se manifesta na interação entre componentes, e não necessariamente no componente onde foi observado. Por isso o trabalho da equipe nesse nível inclui rastrear a origem do problema e determinar quais componentes precisam ser depurados.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Integração: localizar a origem do defeito entre os componentes","citation":null,"trap_note":"É por causa desse custo de localização que a integração incremental é recomendada: integrando poucos componentes por vez, o defeito novo provavelmente está no que acabou de entrar."}},{"id":"4687ff5966e9","number":66,"stem":47,"statement":"Testes de aceitação buscam garantir que o sistema opere com cargas de trabalho variáveis, visto que o aumento progressivo dessas cargas leva à compreensão do momento em que o desempenho se tornará inaceitável.","answer":"E","source":{"slug":"TCE_PA_16","ano":2016},"explanation":{"verdict_reason":"Aumentar progressivamente a carga até identificar o ponto em que o desempenho se torna inaceitável é o propósito dos testes de carga e de estresse. O teste de aceitação tem outra função: confrontar o sistema com a necessidade do cliente, para decidir se ele pode ser aceito e colocado em uso. A descrição pertence a outro tipo de teste.","distortion_type":"troca_de_termo","distorted_span":"Testes de aceitação buscam garantir que o sistema opere com cargas de trabalho variáveis","corrected_statement":"Testes de estresse buscam garantir que o sistema opere com cargas de trabalho variáveis, visto que o aumento progressivo dessas cargas leva à compreensão do momento em que o desempenho se tornará inaceitável.","concept":"Aceitação × estresse: necessidade do cliente × comportamento sob carga crescente","citation":null,"trap_note":"Este molde se repete com nomes diferentes: a descrição de carga ou estresse assinada como aceitação, integração ou regressão. Identifique a descrição primeiro, o nome depois."}},{"id":"7628ec87d0b4","number":67,"stem":47,"statement":"Na aplicação de versões mais recentes do software, caso seja verificada a ocorrência de novos defeitos em componentes já analisados, os testes de unidade rejeitarão o software, interpretando ter havido violação das assinaturas de entrada e saída.","answer":"E","source":{"slug":"TCE_PA_16","ano":2016},"explanation":{"verdict_reason":"Defeito novo que aparece em componente já analisado depois de uma nova versão é matéria de teste de regressão, e o que ele revela é mudança de comportamento, não violação de assinatura de entrada e saída. Assinatura incompatível é erro detectado na compilação ou na integração, e passar no teste de unidade nunca é mecanismo de aceitar ou rejeitar a liberação do software.","distortion_type":"troca_de_termo","distorted_span":"os testes de unidade rejeitarão o software, interpretando ter havido violação das assinaturas de entrada e saída","corrected_statement":"Na aplicação de versões mais recentes do software, caso seja verificada a ocorrência de novos defeitos em componentes já analisados, os testes de regressão apontarão a introdução de defeitos em funcionalidades que antes operavam corretamente.","concept":"Defeito reintroduzido por nova versão é achado de regressão","citation":null,"trap_note":"Ligue a causa ao nível: mudança de versão quebrando o que funcionava é regressão; incompatibilidade de interface entre módulos é integração; erro dentro do método é unidade."}},{"id":"5351b352de88","number":68,"stem":48,"statement":"No JUnit, os testes são realizados em sequência, por isso eles mantêm uma relação de dependência entre si.","answer":"E","source":{"slug":"FUNPRESP_16_JUD","ano":2016},"explanation":{"verdict_reason":"O princípio que rege os testes no JUnit é o inverso: cada teste deve ser independente dos demais, preparar o próprio cenário e não deixar resíduo para o seguinte. Justamente por isso a ordem de execução não é garantida por padrão, e nenhum teste pode depender do resultado de outro.","distortion_type":"inversao","distorted_span":"eles mantêm uma relação de dependência entre si","corrected_statement":"No JUnit, os testes são independentes entre si, de modo que nenhum deles pode depender do resultado ou da ordem de execução dos demais.","concept":"Independência entre testes no JUnit","citation":null,"trap_note":"Independência é o I do FIRST e aparece tanto em item conceitual quanto em item de ferramenta. A oração por isso costuma ser o disfarce de uma causa inventada."}},{"id":"24e4ee2f3303","number":68,"stem":47,"statement":"Testes de integração buscam assegurar que o sistema opere com a carga necessária, pois, ao aumentá-la progressivamente, pode-se avaliar se as interações entre componentes são satisfatórias.","answer":"E","source":{"slug":"TCE_PA_16","ano":2016},"explanation":{"verdict_reason":"O teste de integração não se define por carga. Ele exercita as interfaces entre componentes já testados isoladamente, procurando erro de parâmetro, de contrato e de suposição mútua, com volumes normais de operação. Avaliar o sistema sob carga crescente é objetivo do teste de carga ou de estresse.","distortion_type":"troca_de_termo","distorted_span":"buscam assegurar que o sistema opere com a carga necessária","corrected_statement":"Testes de integração buscam assegurar que os componentes do sistema operem corretamente em conjunto, pois, ao exercitar suas interfaces, pode-se avaliar se as interações entre componentes são satisfatórias.","concept":"Integração avalia interfaces, não capacidade de carga","citation":null,"trap_note":"A presença da palavra carga, ou de aumento progressivo, praticamente elimina os níveis de unidade, integração e aceitação como resposta correta."}},{"id":"06649bd57da6","number":75,"stem":49,"statement":"No nível F do MPS/BR, em que são executados testes com validação e verificação e definidos requisitos, ainda há muita dependência do fator humano, mas a tendência é essa dependência se reduzir drasticamente nos níveis posteriores, até o processo se tornar automático.","answer":"E","source":{"slug":"SEE_16_DF","ano":2016},"explanation":{"verdict_reason":"Verificação, validação e desenvolvimento de requisitos são processos do nível D (largamente definido) do MR-MPS-SW, não do nível F. O nível F reúne gerência de configuração, garantia da qualidade, medição e aquisição. A prática descrita existe no modelo, mas está ancorada no nível errado.","distortion_type":"atribuicao_errada","distorted_span":"No nível F do MPS/BR","corrected_statement":"No nível D do MPS/BR, em que são executados testes com validação e verificação e definidos requisitos, ainda há muita dependência do fator humano, mas a tendência é essa dependência se reduzir nos níveis posteriores.","concept":"MPS/BR: verificação e validação são processos do nível D","citation":"MR-MPS-SW (MPS.BR), níveis G a A","trap_note":"A ordem dos níveis do MPS/BR é G, F, E, D, C, B, A, do menos para o mais maduro. Guarde as âncoras: G tem gerência de projeto e de requisitos, F tem configuração, qualidade e medição, D tem requisitos, projeto, integração, verificação e validação."}},{"id":"1d8cb8d133b3","number":96,"stem":50,"statement":"O objetivo da tarefa de validação, realizada na etapa de análise de requisitos, consiste em assegurar que o software atenderá às necessidades levantadas pelo cliente.","answer":"C","source":{"slug":"FUB_16_1","ano":2016},"explanation":{"verdict_reason":"A validação de requisitos, feita ainda na análise, confronta o que foi especificado com a necessidade real levantada junto ao cliente, procurando requisito ambíguo, incompleto, conflitante ou que simplesmente não resolve o problema. É a pergunta estamos especificando o produto certo, aplicada antes de haver código.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"Validação de requisitos: a especificação atende à necessidade do cliente","citation":null,"trap_note":"Validação não acontece só no fim. Ela começa na análise de requisitos e termina no teste de aceitação, mas a pergunta é sempre a mesma: é isto que o cliente precisa?"}},{"id":"bd215c252eb6","number":99,"stem":50,"statement":"Os testes de integração servem para verificar se o sistema desenvolvido está em conformidade com os requisitos levantados.","answer":"E","source":{"slug":"FUB_16_1","ano":2016},"explanation":{"verdict_reason":"Confrontar o sistema construído com os requisitos levantados junto ao cliente é o objetivo do teste de aceitação, que é atividade de validação. O teste de integração tem escopo bem mais estreito: verifica se os componentes já testados isoladamente funcionam corretamente quando combinados, atacando erros de interface.","distortion_type":"troca_de_termo","distorted_span":"Os testes de integração","corrected_statement":"Os testes de aceitação servem para verificar se o sistema desenvolvido está em conformidade com os requisitos levantados.","concept":"Integração olha interfaces; aceitação olha requisitos do cliente","citation":null,"trap_note":"A palavra requisitos levantados aponta para o cliente, logo para validação e aceitação. Integração nunca é o nível em que se julga se o sistema é o que o usuário pediu."}}]}