Um atributo de um componente ou sistema especificado ou implícito na documentação de requisitos.

Um aspecto da base de teste que é relevante para alcançar objetivos específicos de teste.

O grau em que um produto de software fornece funções que atendem às exigências declaradas e implícitas

O grau em que um produto de software fornece funções que atendem às exigências declaradas e implícitas precisa quando o software é usado sob condições especificadas.

A porcentagem de todos os resultados de uma condição que afetam independentemente uma decisão resultado exercido por uma suíte de testes.

O teste deve começar o mais tarde possível, para que o desenvolvimento tenha tempo suficiente para criar um bom produto.

Encontrar o maior número possível de falhas para que os defeitos possam ser identificados e corrigidos

Para provar que todos os defeitos possíveis são identificados.

Para provar que qualquer defeito remanescente não causará falhas.

O teste identifica a fonte dos defeitos; a depuração analisa os defeitos e propõe atividades de prevenção.

O teste dinâmico mostra falhas causadas por defeitos; a depuração localiza, analisa e remove as causas de falhas no software.

O teste remove defeitos; a depuração identifica as causas das falhas.

O teste dinâmico evita as causas das falhas; a depuração remove as falhas.

O produto travou quando o usuário selecionou uma opção em uma caixa de diálogo.

A versão incorreta de um arquivo de código-fonte compilado foi incluída na compilação.

O algoritmo de computação usou as variáveis de entrada incorretas.

O desenvolvedor interpretou mal o requisito do algoritmo.

Testing depends on the environment.

Exhaustive testing is not possible.

Repeating of tests will not find new defects.

Defects cluster together.

Garante que os requisitos sejam detalhados o suficiente.

Contribui para a obtenção da qualidade de várias maneiras.

Garante que os padrões da organização sejam seguidos.

Mede a qualidade do software em termos de número de casos de teste executados.

Identificando qualquer infraestrutura e ferramentas necessárias.

Criando conjuntos de testes a partir de scripts de teste.

Analisando as lições aprendidas para melhoria de processos.

Avaliando a base de teste para testabilidade.

1A, 2C, 3B, 4D.

1D, 2B, 3A, 4C.

1A, 2C, 3D, 4B.

1D, 2C, 3B, 4A.

Verificar se grandes volumes de dados podem ser transferidos entre sistemas integrados.

Verificar se todas as instruções de código e caminhos de decisão de código foram executados.

Verificar se todos os fluxos do processo de trabalho foram cobertos.

Para cobrir todas as navegações da página da web.

O teste de componente verifica a funcionalidade dos módulos de software, objetos de programa e classes que podem ser testados separadamente, enquanto o teste do sistema verifica interfaces entre componentes e interações entre diferentes partes do sistema.

Os casos de teste para teste de componentes geralmente são derivados de especificações de componentes, especificações de projeto ou modelos de dados, enquanto que casos de teste para testes de sistema geralmente são derivados de especificações de requisitos ou casos de uso.

O teste de componentes se concentra apenas nas características funcionais, enquanto o teste do sistema se concentra nas características funcionais e não funcionais.

O teste de componente é de responsabilidade dos testadores, enquanto o teste de sistema geralmente é de responsabilidade dos usuários do sistema.

O objetivo do teste de regressão é verificar se a correção foi implementada com êxito, enquanto o objetivo do teste de confirmação é confirmar que a correção não tem efeitos colaterais.

O objetivo do teste de regressão é detectar efeitos colaterais indesejados, enquanto o objetivo do teste de confirmação é verificar se o sistema ainda está funcionando em um novo ambiente.

O objetivo do teste de regressão é detectar efeitos colaterais indesejados, enquanto o objetivo do teste de confirmação é verificar se o defeito original foi corrigido.

O objetivo do teste de regressão é verificar se a nova funcionalidade está funcionando, enquanto o objetivo do teste de confirmação é verificar se o defeito original foi corrigido.

A definição dos requisitos, o design do software e os testes são feitos em fases nas quais, em cada fase, uma parte do sistema é adicionada.

Uma fase no processo de desenvolvimento deve começar quando a fase anterior estiver concluída.

O teste é visto como uma fase separada, que ocorre após o desenvolvimento ter sido concluído.

O teste é adicionado ao desenvolvimento como um incremento.

Decisão para testar a capacidade de manutenção do software.

Decisão de testar o sistema após a migração para uma nova plataforma operacional.

Decisão para testar se é possível recuperar dados arquivados.

Decisão de testar após “hot fixes”.

Desenvolvedor, Moderador, Líder de revisão, Testador.

Autor, Moderador, Gerente, Desenvolvedor.

Autor, Gerente, Líder de revisão, Designer.

Autor, Moderador, Líder de revisão, Escriba.

Coleção de métricas para a avaliação da eficácia da revisão.

Responda a quaisquer perguntas que os participantes possam ter.

Verificação dos critérios de entrada para a revisão.

Avaliação dos resultados da revisão com base nos critérios de saída.

Revisão informal.

Revisão técnica.

Inspeção.

Passo a passo.

O ponto ii) da lista de verificação foi violado porque não está claro qual condição deve ser cumprida para convidar para a revisão.

Você percebe que, além do testador e do verificador, o validador também deve ser convidado. Como este item não faz parte da sua lista de verificação, você não cria um comentário correspondente.

O ponto iii) da lista de verificação foi violado, pois não está claro o que marca a revisão como concluída.

O ponto i) da lista de verificação foi violado porque não está claro quem está fornecendo a lista de verificação para o convite para a revisão.

Uma técnica de teste na qual os testes são derivados com base no conhecimento de falhas passadas do testador ou no conhecimento geral de falhas.

Procedimento para derivar e / ou selecionar casos de teste com base em uma análise da especificação, funcional ou não-funcional, de um componente ou sistema sem referência à sua estrutura interna.

Uma técnica de teste baseada na experiência, na qual o testador experiente usa uma lista de itens a serem observados, verificados ou lembrados, ou um conjunto de regras ou critérios com base nos quais um produto deve ser verificado.

Uma abordagem para testar onde os testadores projetam e executam dinamicamente testes com base em seu conhecimento, na exploração do item de teste e nos resultados de testes anteriores.

Qual das seguintes opções é categorizada como uma técnica de teste de caixa preta?

Uma técnica que verifica se o objeto de teste está funcionando de acordo com o projeto técnico.

Uma técnica baseada no conhecimento de falhas passadas ou no conhecimento geral de falhas.

Uma técnica baseada em requisitos formais.

A afirmação é verdadeira. Qualquer caso de teste único fornece 100% de cobertura de declaração e, portanto, 50% de cobertura de decisão.

A afirmação é verdadeira. Qualquer caso de teste único faria com que o resultado da instrução "if" fosse verdadeiro ou falso.

A afirmação é falsa. Um único caso de teste pode garantir apenas 25% de cobertura de decisão nesse caso.

A afirmação é falsa. A afirmação é muito ampla. Pode estar correto ou não, dependendo do software testado.

É uma métrica, que é a porcentagem de casos de teste que foram executados.

É uma métrica, que é a porcentagem de instruções no código fonte que foram executado.

É uma métrica, que é o número de instruções no código fonte que foram executado por casos de teste que são aprovados.

É uma métrica, que fornece uma confirmação verdadeira / falsa se todas as instruções forem cobertas ou não.

100% de cobertura de decisão também garante 100% de cobertura de declaração.

100% de cobertura de declaração também garante 100% de cobertura de decisão.

A cobertura de decisão de 50% também garante cobertura de declaração de 50%.

A cobertura de decisão nunca pode chegar a 100%.

Quando a pressão do tempo requer acelerar a execução dos testes já especificados.

Quando o sistema é desenvolvido de forma incremental e não há nenhuma carta de teste disponível.

Quando houver testadores disponíveis, que tenham conhecimento suficiente de aplicativos e tecnologias.

Quando já existe um conhecimento avançado do sistema e devem ser fornecidas evidências que deve ser testado intensivamente.

3.

5.

2.

4.

0, 49, 50, 54, 59, 60.

50, 55, 60.

49, 50, 54, 55, 60, 62.

50, 51, 55, 56, 60, 61.

Verifique se o aplicativo pode reproduzir um vídeo em uma tela de tamanho 1920x1080 (1 caso de teste).

Verifique se o aplicativo pode reproduzir um vídeo em uma tela de tamanho 640x480 e 1920x1080 (2 casos de teste).

Verifique se o aplicativo pode reproduzir um vídeo em cada um dos tamanhos de tela no requisito (4 casos de teste).

Verifique se o aplicativo pode reproduzir um vídeo em qualquer um dos tamanhos de tela no requisito (1 caso de teste).

O gerente de teste planeja as atividades de teste e escolhe os padrões a serem seguidos, enquanto o testador escolhe as ferramentas e define as diretrizes de uso das ferramentas.

O gerente de teste planeja e controla as atividades de teste, enquanto o testador especifica os testes e decide a estrutura de automação de testes.

O gerente de teste planeja, monitora e controla as atividades de teste, enquanto o testador projeta testes e decide a liberação do objeto de teste.

O gerente de teste planeja e organiza o teste e especifica os casos de teste, enquanto o testador prioriza e executa os testes.

Porcentagem de casos de teste executados.

Número médio de testadores envolvidos na execução do teste.

Cobertura de requisitos por código fonte.

Porcentagem de casos de teste já criados e revisados.

Medidas de confiabilidade, cobertura de teste, custo de teste, cronograma e status sobre correção de erros e riscos restantes.

Medidas de confiabilidade, cobertura de teste, grau de independência do testador e integridade do produto.

Medidas de confiabilidade, cobertura de teste, custo de teste, disponibilidade do ambiente de teste, tempo de colocação no mercado e integridade do produto.

Tempo de colocação no mercado, defeitos restantes, qualificação do testador, disponibilidade de casos de uso testáveis, cobertura e custo do teste.

Definir critérios de aprovação / reprovação e objetivos do teste.

Desvios da abordagem de teste.

Medições do progresso real em relação aos critérios de saída.

Avaliação da qualidade do item de teste.

Metódico, analítico, reativo e avesso à regressão.

Analítico, baseado em modelo, consultivo e reativo.

Baseado em modelo, metódico, analítico e consultivo.

Regressão avessa, consultiva, reativa e metódica.

Orçamento usado por um projeto de teste semelhante anterior.

Experiência geral coletada em entrevistas com gerentes de teste.

Estimativa de esforço para automação de teste acordado na equipe de teste.

Média de cálculos coletados de especialistas em negócios.

O resultado atual do teste.

Dados que identificam a máquina de café testada.

Status do defeito.

Ideias para melhorar o caso de teste.

É fácil criar testes de regressão.

É fácil manter o controle de versão dos ativos de teste.

É fácil projetar testes para testes de segurança.

É fácil executar testes de regressão.

1A, 2B, 3D, 4C.

1B, 2C, 3D, 4A.

1A, 2C, 3D, 4B.

1B, 2C, 3A, 4D.