SóProvas



Questões de Teste de Software


ID
5011
Banca
CESGRANRIO
Órgão
TCE-RO
Ano
2007
Provas
Disciplina
Engenharia de Software
Assuntos

O teste alfa (alpha test) é conduzido pelo:

Alternativas
Comentários
  • Testes Alpha, Beta e Gama.
    http://imasters.uol.com.br/artigo/9572/des_de_software/teste_de_software/

    Em casos especiais de processos de desenvolvimento de software - Sistemas Operacionais, Sistemas Gerenciadores de Bancos de Dados (SGBD), e outros softwares comerciais disponibilizados no mercado nacional e internacional - os testes requerem fases também especiais antes do produto ser disponibilizado a todos os usuários.

    O período entre o término do desenvolvimento e a entrega é conhecido como fase alpha e os testes executados nesse período, como testes alpha. PRESSMAN afirma que o teste alpha é conduzido pelo cliente no ambiente do desenvolvedor, com este "olhando sobre o ombro" do usuário e registrando erros e problemas de uso.
    Completada a fase alpha de testes, são lançadas a grupos restritos de usuários, versões de teste do sistema denominadas versões beta. O Teste Beta também é um teste de aceitação voltado para softwares cuja distribuição atingirá grande número de usuários de uma ou várias empresas compradoras. PRESSMAN afirma que o teste beta é conduzido em uma ou mais instalações do cliente, pelo usuário final do software. Diferente do teste alpha, o desenvolvedor geralmente não está presente. Conseqüentemente, o teste beta é uma aplicação "ao vivo" do software num ambiente que não pode ser controlado pelo desenvolvedor. O cliente registra todos os problemas (reais ou imaginários) que são encontrados durante o teste beta e os relata ao desenvolvedor em intervalos regulares. Com o resultado dos problemas relatados durante os testes beta, os engenheiros de software fazem modificações e depois se preparam para liberar o produto de software para toda a base de clientes.

    Os testes Gama não são propriamente testes de software. A comunidade do teste de software usa este termo de forma sarcástica referindo-se aos produtos que são mal testados e são entregues aos usuários ("end-users") para que estes encontrem os defeitos já em fase de produção.
  • PRESSMAN afirma que o teste alfa é conduzido pelo cliente no ambiente do desenvolvedor, com este "olhando sobre o ombro" do usuário e registrando erros e problemas de uso.
  • Na Wikipedia, 

    versão alpha (ou alfa) de um produto (geralmente uma aplicação da área de informática) é normalmente definida quando este produto ainda está em fase de construção e testes. Mas só os programadores envolvidos têm acesso, e não ao publico em geral. Porém, os usuários que serão beneficiados com o software poderão testar o sistema em um ambiente controlado nas instalações do desenvolvedor, caracterizando o processo denominado teste alpha.

  • Letra B


ID
5116
Banca
CESGRANRIO
Órgão
EPE
Ano
2007
Provas
Disciplina
Engenharia de Software
Assuntos

Devido ao aumento da demanda por aplicações que funcionem 24 horas por dia na Internet, um software deve ser capaz de manter-se em operação após uma determinada falha. A estratégia de teste que melhor garante essa característica é o(a):

Alternativas
Comentários
  • Teste de recuperação, no contexto da engenharia de software, é um teste utilizado para verificar a robustez e também a capacidade de um determinado software para retornar a um estado operacional após estar em um estado de falha.
    Fonte: http://pt.wikipedia.org/wiki/Teste_de_recuperação
  • Teste de Recuperação: é um teste do sistema que força o software a falhar de várias formas e verifica se a recuperação é executada corretamente. 

    Alternativa: B

  • Alunos, o teste ideal é o Teste de Recuperação, pois por meio dele conseguimos verificar a densidade e robustez e o próprio tempo de capacidade de um determinado software de retornar em caso de uma queda ou falha deste.

    Resposta: C


ID
5425
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2006
Provas
Disciplina
Engenharia de Software
Assuntos

Uma estratégia de teste de software integra métodos de projeto de casos de teste em uma série bem planejada de passos, que resultam na construção bem sucedida de um software. O objetivo principal do projeto de casos de teste é originar um conjunto de testes que tenha a maior probabilidade de detectar erros no software. Sobre as estratégias e técnicas de teste de software, assinale a afirmativa correta.

Alternativas
Comentários
  • Os testes de caixa preta são projetados para validar os requisitos funcionais, sem se preocupar com o funcionamento interno de um programa. As técnicas de teste de caixa preta concentram-se no domínio de informações do software, derivando os casos de teste ao dividir a entrada e a saída de uma maneira que proporcione uma satisfatória cobertura de teste. O particionamento de equivalência divide o domínio de entrada em classes de dados que provavelmente exercitarão uma função de software específica. A análise do valor de fronteira prova a capacidade que um programa tem de manipular dados nos limites da aceitabilidade. o grafo de causa-efeito é uma técnica que possibilita que o analista valide conjuntos complexos de ações e condições.

    Os projetistas de softwares experientes frequentemente dizem: " a atividade de teste nunca termina; ela é apenas transferida do projetista para o seu cliente. toda vez que o seu cliente usa o programa, um teste é realizado". Ao aplicar o projeto de casos de teste, o engenheiro de software pode realizar testes mais completos e, portanto, descobrir e corrigir o maior número de erros possíveis antes que os "testes do cliente" se iniciem.
  • Os teste de caixa branca focalizam a estrutura de controle do programa. Os casos de teste são derivados para garantir que todas as instruções do programa tenham sido exercitadas pelo menos uma vez durante os testes e que todas as condições lógicas tenham sido exercitadas. Os testes de caminho básico , uma técnica de caixa branca, faz uso de grafos de programa para derivar o conjunto de testes linearmente independentes que garantirá cobertura. Os testes de fluxo de dados e das condições põem à prova lógica do programa, e os testes de laços complementam outras técnicas de caixa branca ao proporcionar um procedimento para exercitar laços de vários graus de complexidade.

    Os teste de caixa branca são "testes em pequeno porte" (testing in the small). A implicação dessa colocaçxão é que os teste de caixa branca são tipicamente aplicados a componentes de programas pequenos (Os módulos). Os testes de caixa preta, por outro lado, ampliam o nosso foco e poderiam ser denominados "testes em grande porte" (testing in the large ).
  • http://www.dcc.ufrj.br/~schneide/es/2000/1/a1/al13_20.htm

    O objetivo principal do projeto de casos de teste é derivar um conjunto de teste que tenham alta probabilidade de revelar defeitos no software. Para atingir esse objetivo, duas categorias diferentes de técnicas de projeto de caso de teste são usadas: O teste de caixa preta e o teste de caixa branca.
  • Teste de Funcionalidade

    Busca analisar as funcionalidades dos cenários conforme especificação, validando as regras de negócio. Além dos cenários básicos, são também verificadas contingências de acordo com os cenários de exceção. Em ciclos de teste contínuos, através do versionamento das liberações, podem ser realizados testes de regressão para garantir que funcionalidades já testadas continuam funcionando corretamente após alterações. Este tipo de teste é normalmente utilizado em todos os projetos, já que objetiva a correta implementação das regras de negócio do produto.
  • Teste de Interface

    Busca analisar a interface da aplicação testada, compreendendo navegação entre as janelas, preenchimento de campos e utilização de máscaras. São levadas em consideração contingências na interface, através da inserção de valores inválidos e tentativa de utilização inesperada das janelas. Este tipo de teste é tipicamente realizado em conjunto com teste funcional, buscando garantir a correta implementação das janelas, campos e textos.
  • Teste de Usabilidade

    Simula as condições de utilização do software sob a perspectiva do usuário final, focando na facilidade de navegação entre as janelas da aplicação, clareza dos textos e mensagens que são apresentadas ao usuário. Ao contrário de outros tipos de teste, não existe uma lista de itens pré-determinados a serem conferidos numa verificação padrão de usabilidade, pois cada cliente precisa ser avaliado de forma independente através de bom senso, experiência técnica e conhecimento de usabilidade (requerendo testadores especialistas). Contudo, estes testes tipicamente geram melhorias importantes na interface, tornando o aplicativo mais amigável e intuitivo, gerando maior satisfação do usuário final.
  • Teste de Carga/Performance

    Simula a utilização da aplicação por diversos usuários simultâneos, buscando encontrar problemas na infra-estrutura, hardware ou banda do servidor. Pode-se simular qualquer quantidade de usuários acessando o cliente, gerando relatórios complexos o suficiente para analisar cada serviço web de forma separada, possibilitando à Zero-Defect indicar qual web-service ou acesso ao banco está causando gargalo no sistema. Como este tipo de teste necessita de ferramentas especializadas, normalmente há a necessidade de orçar o valor da ferramenta a ser utilizada.
  • Teste de Recuperação

    Avalia o comportamento do sistema após ocorrência de erro, sobrecarga ou condições anormais, como queda de luz e rede. Nestes testes são tipicamente simulados cenários inesperados da mesma forma que ocorrem nos ambientes reais, como a remoção forçada de um cabo de rede, o desligamento repentino da energia, etc.
  • Teste de Configuração

    Valida os procedimentos de instalação e navegação básica de uma aplicação nos mais diversos ambientes (sistema operacional, browser, hardware, etc), além de avaliar se estes possibilitam as alternativas previstas nos requisitos identificados. Diversos ambientes de cliente e servidor podem ser simulados dentro da Zero-Defect, sendo que também é possível instalar ou utilizar peças de hardware específicas recebidas do cliente, caso necessário.
  • Teste de Configuração

    Valida os procedimentos de instalação e navegação básica de uma aplicação nos mais diversos ambientes (sistema operacional, browser, hardware, etc), além de avaliar se estes possibilitam as alternativas previstas nos requisitos identificados. Diversos ambientes de cliente e servidor podem ser simulados dentro da Zero-Defect, sendo que também é possível instalar ou utilizar peças de hardware específicas recebidas do cliente, caso necessário.
  • ===Letra A=== (ERRADO)

    Teste de caixa preta

    - Usa a especificação de um sistema para identificar as partições de equivalência.

    - Não é preciso de nenhum conhecimento de como funciona o sistema.

    - Também chamado de teste comportamental, focaliza os requisitos funcionais do software.

    - Tipos de teste de caixa preta: Particionamento e equivalência, Analise de valor limite, Teste baseado em modelos

    ===Letra B=== (ERRADO)

    Teste de caixa branca

    - Também chamado de teste da caixa-de-vidro, é uma filosofia do projeto de casos de teste que usa a estrutura de controle descrita como parte do projeto no nível de componentes para derivar casos de teste.

    - Pode-se olhar o código do programa para encontrar outros testes possíveis.

    - Trata-se de uma visão interna de um produto.

    - Tipos de teste de caixa branca: Teste de caminho básico, Teste de ciclo

    ===Letra C=== (ERRADO)

    Teste de integração: é uma técnica sistemática para construir a arquitetura de software ao mesmo tempo que conduz testes para descobrir erros associados com interfaces

    ===Letra D===

    O teste de recuperação é um teste de sistema que força o software a falhar de diversos modos e verifica se a recuperação é adequadamente realizada, seja ela feita de forma automática (realizada pelo próprio sistema) ou requerendo intervenção humana. (CERTO)

    ===Letra C=== (ERRADO)

    Teste alfa: os usuários do software trabalham com a equipe de desenvolvimento para testar o software no local do desenvolvedor.

    Teste beta: é conduzido nas instalações dos usuários finais. O desenvolvedor não está presente nesse teste.


ID
8251
Banca
ESAF
Órgão
Receita Federal
Ano
2005
Provas
Disciplina
Engenharia de Software
Assuntos

Analise as seguintes afirmações relacionadas a Teste de Software:

I. Um critério de cobertura de teste é uma regra sobre como selecionar testes e quando parar o processo de testes.

II. No critério de teste denominado "teste de todos os ramos" o objetivo é passar por ambos os caminhos em todas as decisões. No teste de subdomínio a idéia é particionar o domínio de entrada em subdomínios mutuamente exclusivos, requerendo um número igual de casos de teste de cada subdomínio. A idéia de subdividir subdomínios é eficaz quando se deseja isolar erros potenciais dentro dos subdomínios individuais.

III. No teste funcional, o critério de "cobertura de todo o comando" especifica que todo comando do código fonte deve ser executado por algum caso de teste.

IV. A seleção dos casos de teste baseada na especificação é denominada teste estrutural.

Indique a opção que contenha todas as afirmações verdadeiras.

Alternativas
Comentários
  • I. Certo. A cobertura de testes é um critério usado para determinar se um programa foi suficientemente testado, além de ser uma indicação direta dos defeitos potenciais e custos futuros com manutenção. Existem ferramentas que, utilizando este critério, buscam melhorar a qualidade dos testes, permitindo assim a melhoria da qualidade do software que está sendo desenvolvido. Tais ferramentas, por exemplo, podem detalhar quais blocos de código do software nunca são utilizados.

    II. Certo. Em inglês chama-se Branch Testing. Mais em: http://gsd.ime.usp.br/seminars/testedepuracao.pdf e http://www.bullseye.com/coverage.html

    III. Errado. O critério de TESTE ESTRUTURAL, o qual é baseado na estrutura do código fonte, mais simples é o de COBERTURA DE TODO COMANDO, também chamado de cobertura C0. O teste de cobertura de todo comando diz que todo comando de código fonte deve ser executado por algum caso de teste.

    IV. Errado. Como "especificação" entenda-se documentos de análise elaborados utilizando a linguagem UML, por exemplo. O teste estrutural é apoiado na implementação, isto é, no fluxo de controle e informações dos fluxos dos dados. Utilizam também os erros típicos do processo de desenvolvimento de software para derivar os requisitos de teste. Já o teste funcional é apoiado na especificação funcional do software;

    Mais em: http://www.async.com.br/~kiko/papers/testcriteria/ , www.pucrs.br/inf/eventos2003/ workshop/arquivo/MiniCurso_Teste.pdf e http://www.cnptia.embrapa.br/modules/tinycontent3/content/2003/bp10.pdf
  • teste funcional é tb black box testing (comportamento) e estao relacionados ao teste de requisitos funcionais. estes testes incluem unidade, integracao, systema, interface, regressao e beta/aceite. testes nao funcionais tb sao white box testing ou testes estruturais e testam algoritmo ou codigo. eles envolvem: performance, stress, volume, segurança, compatbilidade, instalacao, recovery. usabilidade etc


ID
17758
Banca
CESGRANRIO
Órgão
BNDES
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

No âmbito de estratégias e técnicas de testes de software, assinale a afirmativa correta.

Alternativas
Comentários
  • Tipos de Teste Caixa Preta:
    1. Teste baseado em grafos
    2. Particionamento de equivalência
    3. Análise de valor-limite
    4. Teste de matriz ortogonal
    -----
    Tipos de teste Caixa Branca:
    – Teste de Caminho Básico
    – Teste de Estrutura de Controle
    - Teste de Condição
    - Teste de Fluxo de Dados
    - Teste de Ciclos ("loops")
  • são todos testes relacionados aos principais problemas que ocorrem em aplicações cliente-servidor, antes de implantar uma aplicação do tipo, nada mais conveniente que executar o teste funcional da aplicação cliente, testar o correto funcionamento do servidor, antes e após o deploy, testar o banco de dados, testar se o sistema de controle de transações está dentro dos eixos e o mais importante de todos, testar a comunicação através da rede.

    Na letra A o problema está quando ele afirma que não é recomendado automatizar os testes de regressão, os testes de regressão são testes executados após alguma alteração no sistema, situação na qual geralmente o tempo é um recurso escasso, o que praticamente obriga a automatização dos testes.Na letra C, o teste de Particionamento de equivalência faz parte dos testes de Caixa Preta e não Caixa Branca como diz a alternativa.Na letra D, a validação está mais ligada ao cliente ou usuário, pois "valida" se o que foi construido está de acordo com as especificações dos requisitos:

    - Verificação: "Estamos construindo certo o produto?

    - Validação. “Estamos construindo o produto correto?

    Na letra E, geralmente após os testes de unidade ocorrem diversos outros testes antes da validação, como os testes de integração, testes de módulos, testes de subsistemas dentre outros, a validação está mais ao final, quando comparada aos testes de unidade.

  • sobre a letra B:

    São exemplos de abordagens de testes para aplicações cliente-servidor: teste de função da aplicação cliente (interface com o usuário), teste de servidor (pode ser stress ou carga), teste de banco de dados (performance), teste de transação (volume) e teste de comunicação em rede (controle de acesso).

ID
17926
Banca
CESGRANRIO
Órgão
BNDES
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

No contexto de engenharia de software, testes de software podem ser decompostos numa série de passos que devem ser executados seqüencialmente. Considerando a arquitetura de software convencional, o primeiro passo deve ser o teste de

Alternativas
Comentários
  • Porque nao a letra E? Alguem poderia responder?

    A validacao nao seria primeiro ? Para saber se o projeto esta indo de acordo com o que o cliente queria?
  • segundo pressman no seu livro de engenharia de software uma estratégia de teste de software inicia-se com teste unitário, depois progride para o teste de integração, depois validação e por fim o teste de sistema
  • Primeiro faz-se o teste unitário para saber se o que foi desenvolvido funciona como o que era desejado na etapa de codificação;

    Depois o teste de integração, para saber se as partes funcionam bem juntas.

    Em seguida o teste de validação, para identificar se o que está integrado condiz com o que era desejado.

    Por fim o teste de sistema que vai testar todo o sistema após as mudanças introduzidas nas etapas anteriores.
     

  • Segundo Pressman

    1 - Teste de Unidade

    2 -  Teste de Integração

    3 - Validação

    4 - Sistema


ID
27664
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2004
Provas
Disciplina
Engenharia de Software
Assuntos

Uma das métricas de teste mais utilizadas no mercado é a Análise de Ponto de Teste (TPA - Test Point Analysis). Sobre a TPA é FALSO afirmar que:

Alternativas
Comentários
  • A técnica TPA pode ser usada para preparar uma etsimativa para um teste de sistema ou teste de aceitação. Cobre apenas testes de caixa-preta.
  • Na realidade, os pontos de testes dinâmicos levam em consideração cada função e não o sistema como um todo, que é característica do cálculo dos pontos de testes estáticos.Logo, a letra b) é a resposta mais adequada.

ID
43696
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Um importante aspecto da elaboração de casos de testes para um sistema em desenvolvimento é a escolha dos valores de entrada e das saídas previstas dos casos de teste. Escolhas baseadas apenas em valores típicos, em geral, são incapazes de revelar todas as falhas da implementação. É necessário identificar conjuntos de valores que possuam características comuns, do ponto de vista das funcionalidades a serem testadas, como, por exemplo, "números negativos", "números com mais dígitos do que o previsto", "strings sem brancos", "arrays de um só elemento", além de prever casos de teste cobrindo a totalidade destes conjuntos, e projetar, para cada conjunto, casos de teste com valores nos limites e próximos ao ponto médio do conjunto. Esses conjuntos são denominados

Alternativas
Comentários
  • o particionamento por equivalência é uma técnica de teste da caixa preta, ele seleciona um dominio de entrada de dados de um programa de classe, a partir dos quais os casos de teste possam ser derivados a fim de realização das verificações, Existem mais três tipos de teste da caixa preta que são: a) causa e efeito; b) valor limite; c) comparação
  • Explicando o primeiro comentário, que ficou bem confuso no começo:O particionamento de equivalência divide o domínio de entrada de um programa em classes de dados, das quais os casos de testes podem ser derivados.
  • Segundo Pressman:
    O particionamento de equivalência é um método de teste caixa-preta que divide o domínio de entrada de um programa em classes de dados, das quais os casos de testes podem ser derivados. Ele busca definir um caso de teste que descobre classes de erros, reduzindo assim o número total de casos de testes que precisam ser desenvolvidos.
  • Se a coloca uma alternativa com "análise do valor limite" ficaria muito mais difícil de resolver a questão


ID
56728
Banca
CESPE / CEBRASPE
Órgão
ANAC
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Em engenharia de software, o processo de
desenvolvimento de software designa uma sequência de
atividades, agrupadas em fases e tarefas, executadas de forma
sistemática e uniformizada, realizadas por pessoas com
responsabilidades bem definidas e que, a partir de um conjunto
de entradas (inputs) produzem um conjunto de saídas (outputs).
Como objetivos, o processo de desenvolvimento de software deve
prover orientação sobre as sequências das atividades envolvidas,
especificar os modelos descritivos do sistema, gerenciar as tarefas
e definir métricas para os modelos e atividades.

R. A. Ramos. Treinamento em UML (com adaptações).

Quanto às fases e tarefas no processo de desenvolvimento de
software, julgue os itens de 64 a 67.

Requisitos descrevem um acordo ou contrato entre duas partes, especificando, entre outros aspectos, o que o sistema de software deve fazer para ser aprovado em um teste de aceitação.

Alternativas
Comentários
  • Lembrem da definição de qualidade: atendimento completo aos requisitos definidos. Não tenho uma referência boa para colocar aqui, mas em qualquer framework de gerenciamento os requisitos precisam ser validados ao final para que se garanta o atingimento da qualidade.

ID
70282
Banca
FCC
Órgão
TRT - 3ª Região (MG)
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

O processo de teste repetido continuamente até que o cliente e o projetista concordem que a versão liberada seja uma implementação aceitável dos requisitos do sistema desenvolvido sob encomenda de um único cliente é chamado teste de aceitação ou teste

Alternativas
Comentários
  • No teste alfa o projetista participa. No teste beta o software está no ambiente de produção sendo usado somente pelo cliente que, eventualmente, reporta os problemas ao projetista.
  • questao que nao esta de acordo com o Pressman, 6 ediçao pagina 304, o teste alfa seria para varios clientes, e nao um unico cliente!!!!!!!
  • Teste Alfa não tem a ver com a quantidade de clientes, mas sim com o ambiente em que o teste está sendo feito (no caso ambiente de desenvolvimento).
  • Concordo com marciah, mas essa questão foi tirada do Pressman, no capítulo "Teste de Aceitação". Nele, o teste alfa é feito em um ambiente controlado pelo desenvolvedor e em apenas UM cliente. Diferente do teste alfa, o teste beta, segundo Pressman, é realizado em um ambiente não controlado pelo desenvolvedor e é feito em VÁRIOS clientes.

  • Conforme comentou o colega Leonardo,

    Segundo os conceitos do Pressman, a quantidade de clientes tem sim influência nessa definição de teste Alfa e Beta. Na página 304 (Pressman, 6ª edição). Diz o seguinte:

    "Quando um software sob encomenda é construído para um cliente, uma série de testes de aceitação é conduzida para permitir ao cliente validar todos os requisitos. Conduzido pelo usuário final em vez de pelos engenheiros de software, um teste de aceitação pode variar de uma "volta de teste" informal para uma série de testes planejada e executada sistematicamente.(...)"

    "Se o software é desenvolvido como um produto a ser usado por vários clientes, não é prático realizar testes formais de aceitação com cada um. A maioria dos construtores de produtos de software usa os processos chamados de testes alfa e beta para descobrir erros que o usuário final parece ser capaz de descobrir.(...)"

    Essa questão deveria ser anulada, tendo em vista que ela cita explicitamente o número de clientes (um) e NENHUMA das alternativas atende às definições acima citadas. 

  • Examinador tirou essa questão do Sommerville e não do Pressman. Na página 53 da 8a edição:

    "O teste de aceitação é algumas vezes chamado de teste alfa. Os sistemas sob encomenda são desenvolvidos para um único cliente, o processo de teste alfa continua até que o projetista do sistema e o cliente concordem que o sistema liberado é uma implementação aceitável dos requisitos do sistema."
  • Gabarito letra "A". Pra quem quiser saber mais sobre esses dois tipos de teste, segue um pdf com essas definições nas principais bibliografias desse assunto: http://pt.scribd.com/doc/151374001/Testes-Alfa-e-Beta
  • Autores distintos com pensamentos diferentes.

    Com certeza, esse gabarito foi baseado no Sommerville, como mencionou o colega. Pois, segundo Pressman, o gabarito poderia ser a alternativa B.

    Engenharia de software, 7a. edição, página 418:

    "Uma variação do teste beta, chamada de teste de aceitação do cliente, às vezes é executada quando é fornecido software personalizado a um cliente sob contrato. O cliente executa uma série de testes específicos na tentativa de descobrir erros antes de aceitar o software do desenvolvedor."

  • Alguns pontos a serem considerados:

    - Independente de fonte literária (Sommerville ou Presman), por este trecho da questão "até que o cliente e o projetista concordem que a versão liberada seja uma implementação aceitável" daria para perceber que trata-se de teste alfa. Observe que o software ainda não foi liberado, com isso temos um ambiente controlado (teste alfa).

    - FCC costuma considerar o Sommerville. Fica a dica para quem está focando algum concurso organizado pela FCC.

    Bons estudos!

  • Fui pelos conceitos do Pressman, marquei a letra B e errei.

    Paciência
  • usuario + desenvolvedor = alfa

    usuario sozinho (em seu ambiente obvio) = beta


ID
70339
Banca
FCC
Órgão
TRT - 3ª Região (MG)
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

NÃO se trata de uma técnica para testar software o teste de

Alternativas
Comentários
  • Teste de unidade é uma fase de teste (unidade, integração, sistema, validaçã) e não uma técnica
  • pra mim teste de unidade tb é técnica de teste...os quais testam os códigos menores...
  • Nao tem nada de errado com o gabarito.

    A resposta é letra "d" , teste de unidade nao eh uma tecnica de teste e sim uma fase de teste, assim como: integracao, validacao e sistema.

  • Como o colega falou a resposta é a letra D mesmo.

    A FCC tentou confundir o candidato: confrontando os termos TÉCNICAS DE TESTES X FASES OU ESTRATÉGIAS DE TESTES.

    TÉCNICAS DE TESTE (alguns exemplos):
    - caixa preta;
    - caixa branca
    - caixa cinza
    - estresse ou carga
    - regressão
    - usabilidade
    - etc....

    ESTRATÉGIAS DE TESTE
    -Teste de Unidade
    - Teste de Integração
    - Teste de Sistema
    - Teste de Acaitação
  • A questão foi mal formulada no meu ponto de vista, existem três dimensões de testes:
    Técnicas de Teste (Como Testar?) - Caixa branca e Caixa preta;
    Níveis de Teste (Quando Testar?) - Unidade, integração, sistema e aceitação;
    Tipos de Teste (O que testar?) - Regressão, desempenho, carga e etc...

    Nesse contexto e, ao pé da letra, a única técnica na questão é a de caixa preta.
  • lixo de questão. De acordo com Sommerville 8ª Ed. abordagens como a de Caixa Preta possuem técnicas como a matriz ortogonal, análise de valores limítrofes e etc.

  • Já ao meu ver, seria assim:

    caixa preta: abordagem de teste. No contexto dessa abordagem algumas técnicas podem ser usadas, como matriz ortogonal e grafos.
    regressão: tipo de teste
    desempenho: tipo de teste
    unidade: estágio ou estratégia de teste
    carga: tipo de teste

  • Está pedindo TÉCNICASDE TESTE e não ESTRATÉGIAS DE TESTE  .E segundo Sommerville 8ª Ed.  como o colega citou

    A questão está correta sim.

  • Faltou a FCC(ou o Qconcursos) contextualizarem a questão.

  • A verificação está baseada em três dimensões de testes: tipos de teste, técnicas de teste e níveis de teste.

     

    Tipos de teste - São os da metodologia de qualidade FURPS:

     Funcionalidade:Teste funcional, Teste de regressão, Teste de segurança.

     Usabilidade: Teste de interface, Teste de usabilidade.
     Confiabilidade: Teste de estrutura, Teste de integridade, Smoke test.
     Desempenho: Teste de avaliação de desempenho, Teste de carga.
     Suportabilidade: Teste de configuração, Teste de instalação.

     

    Técnicas de teste: Estrutural ou Funcional. Nos quais:

     Estrutural - Também chamados caixa branca. Verifica se o sistema desenvolvido e os programas estão estruturalmente sólidos e funcionando no contexto técnico onde serão instalados, o foco dos testes é averiguar o comportamento do sistema em determinadas situações. 

     Funcional - Também chamados caixa preta. Assegura que as especificações e os requisitos do software foram atendidos. Foca apenas nas E/S especificadas, não se preocupa com a estrutura interna.

     

    Níveis de teste (ou fases ou, ainda, estratégias de testes) - Teste de Unidade, Teste de integração, Teste de Sistema, Teste de aceitação.


ID
72106
Banca
CESGRANRIO
Órgão
IBGE
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Durante um treinamento para as equipes de desenvolvimento e de testes, um analista transmitiu as orientações a seguir.

I - Para isolar a causa de um erro de software, os desenvolvedores deveriam utilizar a estratégia de depuração força bruta por ser o método mais eficiente, e, para grandes programas, utilizar a abordagem de rastreamento.

II - Para os testes de integração em sistemas orientados a objetos, poderiam ser utilizadas as estratégias de teste com base no caminho de execução e no uso.

III - Em sistemas orientados a objetos, o teste de sensibilidade poderia ser utilizado para tentar descobrir combinações de dados, dentro das classes de entrada válidas, que poderiam causar instabilidade ou processamento inadequado do sistema.

Constitui(em) prática(s) adequada(s) de estratégias de testes de software a(s) orientação(ões)

Alternativas
Comentários
  • Depuração força bruta é o método MENOS eficiente.
  • O teste de sensibilidade, exatamente como descrito na opção III, é uma espécie de especialização do teste de Estresse, mas localiza dados sensíveis (pequeno conjunto que afeta a execução) em vez de achar o ponto do estresse.Opção II exatamente como definido por Pressman. Ele também cita o teste de agrupamento, que é uma etapa do teste de integração da OO.Força bruta só em último caso, não privilegia as técnicas de resolução de problemas. Pode ser inexequível dependendo do tamanho do software.

ID
76906
Banca
CESGRANRIO
Órgão
BACEN
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Em determinado formulário de um sistema WEB, é apresentado um campo de entrada que deve aceitar números inteiros de 10 a 500. De acordo com a análise de valor limite, que valores devem ser testados?

Alternativas
Comentários
  • Um teste de particionamente de análise de valor limite (BVA - boundary value analysis) é um teste de caixa preta que execer testes nos extremos das condições. Executará teste nos extremos e teste imediatamente acima e abaixo dos limites.

    Assim: if (x >= 1) && (x <= 10)

    Executará testes em x==1, x == 10, x == 0 e x == 11.
  • análise de valor limite - Técnica de projeto de teste de caixa preta onde os casos de teste são projetados com base nos valores da fronteira. 

    Fonte: 
    GLOSSÁRIO PADRÃO DE TERMOS UTILIZADOS EM TESTE DE SOFTWARE
    Versão 2.2br (janeiro 2012)
  • a-

    Análise do valor limite testa valores input alem do esperado. ha 3 particoes: partição inválida 1, partição válida e partição inválida 2. as invalidas possuem valores extrapolantes aos esperados, que pertencem à partição válida


ID
79237
Banca
FCC
Órgão
TRT - 18ª Região (GO)
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Uma sistemática para construção da arquitetura do software enquanto, ao mesmo tempo, conduz ao descobrimento de erros associados às interfaces é a estratégia de teste de software denominada de

Alternativas
Comentários
  • Integração. Mas a questão está esquisita. Integração NÃO é uma estratégia de teste de software, mas sim uma FASE do ciclo de vida de teste.O examinador poderia ter tomado mais cuidado...
  • O examinador realmente transcreveu PORCAMENTE uma passagem do pressman:

    "O teste de integração é uma técnica sistemática para construir a arquitetura de software ao mesmo tempo que conduz testes para descobrir erros associados com as interfaces."
  • Teste de Integração:

    https://uploaddeimagens.com.br/imagens/teste_de_software-png

  • e-

    Teste de Unidade: em cada componente isolado, para ver entradas em um ambiente controlado. Inclui estruturas de dados internas, a lógica e as condições limite para os dados de entrada e saída


    Teste de Integração: provoca falhas nas interfaces;


    Teste de Sistema: como usuário. Inclui testes de carga, performance, usabilidade, compatibilidade, segurança e recuperação.

     

    Teste de Aceitação: com usuario.

  • Estratégias de teste:

    Unidade

    Integração

    Validação

    Sistema

    Integração: palavra-chave INTERFACE de unidades.


ID
79240
Banca
FCC
Órgão
TRT - 18ª Região (GO)
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

NÃO se trata de uma categoria de erros encontrados por meio de teste caixa-preta:

Alternativas
Comentários
  • Testes de caminho básico é uma técnica de caixa branca, e possibilita que o projetista do caso de teste derive uma medida da complexidade lógica de um projeto procedimental e use essa medida como guia para definir um conjunto básico de caminhos de execução.
  • Só complementando

    Isso está relacionado ao teste de McCabe, ou teste do caminho básico, que deve executar um conjunto básico do programa.

    Um caminho básico é o conjunto de caminhos de execução em que um programa executa cada um de seus comandos pelo menos uma vez, e as condicionais são executadas tanto quando for verdadeiro quanto quando for falso.

    Um caminho independente é um caminho que introduza um novo conjunto de comandos, ou uma condicional, em sua execução.



  • Segundo Pressman, o teste caixa-preta tenta encontrar erros nas seguintes categorias: (1)Funções incorretas ou faltando, (2)Erros de interface, (3)Erros em estruturas de dados ou acesso a base de dados externas, (4)Erros de comportamento ou desempenho, (5)Erros de inicialização e término.
    (Fonte: Engenharia de Software, 7ed, Pressman, pag 439)
    Gabarito letra "A".

ID
114214
Banca
CESPE / CEBRASPE
Órgão
TRE-MT
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Existem várias maneiras de se depurar (debug) programas. Algumas delas envolvem conhecimento, prática e bom senso do programador. Acerca de pontos que são importantes para depurar programas, julgue os itens a seguir.

I É possível encontrar falhas nos programas por meio da reprodução do erro em testes.

II Quanto maior a entrada de dados nos testes, mais simples é encontrar o problema e mais fácil é encontrar a solução da falha.

III Em um programa modular, o processo de encontrar falhas requer uma menor variação de informações de entrada, de modo que o programador possa encontrar o módulo com erros.

IV A passagem de parâmetros para variáveis auxiliares evita o uso de break points.

V A análise estruturada é a melhor maneira de encontrar erros em programação orientada a objetos.

Estão certos apenas os itens

Alternativas
Comentários
  • Programação modular é um paradigma de programação no qual o desenvolvimento das rotinas de programação é feito através de módulos, que são interligados entre si através de uma interface comum.A principal operação que um debugger permite é a suspensão e continuação da execução de um programa em uma determinada linha de código, através do que chamamos de "breakpoint".Passagem de parâmetros Os parâmetros são dados que recebem as funções e as utilizam para realizar as operações de função. Uma função pode receber qualquer número de parâmetros, ou mesmo nenhum. Na hora de definir a função, no cabeçalho, definem-se os parâmetros que vai receber. function f1 ($parametro1, $parametro2) Assim definimos uma função f1 que recebe dois parâmetros. Como se pode observar, não temos de definir o tipo de dados de cada parâmetro. Os parâmetros tem validede durante a execução da função, isto é, tem um âmbito local à função de onde se recebem.Quando a função termina, os parâmetros deixam de existir. Os parâmetros por valor A passagem de parâmetros em PHP realiza-se por valor. "Por valor" é uma maneira típica de passar parâmetros em funções, quer dizer que a modificação de um parâmetro não actualiza o dado da variável como parâmetro, apesar de mudarmos o valor do parâmetro dentro da função, a variável original não se vê afectada pela mudança.http://www.criarweb.com/artigos/86.phpPassagem de parâmetros por referência Em contraposição à passagem de parâmetros por valor, está a passagem de parâmetros por referência. Neste último caso, a mudança do valor de um parâmetro dentro de uma função afecta o valor da variável original. Podemos passar os parâmetros por referência se, na declaração da função, colocarmos um "&" antes do parâmetro.

ID
118867
Banca
FCC
Órgão
TRT - 20ª REGIÃO (SE)
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

No contexto da estratégia para o teste de um projeto, os estágios de teste desempenham um papel importante. O teste que é aplicado a componentes do modelo de implementação para verificar se os fluxos de controle e de dados estão cobertos e funcionam conforme o esperado, é o teste

Alternativas
Comentários
  •  Essa questão é um tanto controversa, já que em uma grande quantidade de questões que cita componentes o teste comentado é o de integração. Mas, não podemos nos deixar induzir por apenas uma palavra do enunciado nos levar a conclusões errôneas. Fiz um breve resumo dos comentários lidos no TIMasters sobre essa questão:

    Primeiro temos um conceito para eliminar a solução direta: O teste de unidade focaliza o esforço de verificação na menor unidade de projeto do software - o componente ou módulo de software. [2]

    Tendo em vista que componentes também estão associados a testes de unidade, porque não poderia ser também teste de integração. Podemos perceber que a questão trata de testes de muito baixo nível como fluxos de controle e de dados, onde podemos relacioná-los com testes do próprio código do componente, ou seja, testes de unidade.

    Os testes de integração, também relacionados a testes de componentes do software, são bem mais alto nível e são efetuados entre as comunicações existentes entre componentes do sistema e não fluxos internos do componente. Esses testes estão mais relacionados com as saídas que os componentes apresentam uns para os outros.

    Tendo em vista esses conceitos de testes de unidade e de integração, podemos perceber uma estrita relação com os testes de caixa branca e de caixa preta, respectivamente.

     

    [1] TIMasters

    [2] Pressman, 6a ed. pag 295

  • Para matar a questão se atente para essas três palavras entre colchetes:

    No contexto da estratégia para o teste de um projeto, os estágios de teste desempenham um papel importante. O teste que é aplicado a componentes do modelo de [implementação] para verificar se os [fluxos de controle] e de [dados] estão cobertos e funcionam conforme o esperado, é o teste...

  • Teste Unitário

    Tem como principal função testar o menor bloco de software desenvolvido, avaliando os resultados obtidos com entradas de dados pré-definidos.

  • e-

    O teste de unidade comprova uma funcionalidade para verificar seu mecanismo correto. Implica um nivel de teste para testar os detalhes do compoenentes.


ID
119299
Banca
FCC
Órgão
TRF - 4ª REGIÃO
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre os processos de teste de software, considere:

I. Em um processo de desenvolvimento iterativo, o teste de sistema concentra-se no teste de um incremento que será entregue ao cliente.

II. No teste de integração é feito o planejamento de uma série de testes em que a carga é constantemente aumentada até que o desempenho do sistema torne-se aceitável.

III. A única meta do teste de software é descobrir falhas ou defeitos no software que apresenta comportamento incorreto, não desejável ou em não conformidade com sua especificação.

Está correto o que consta em

Alternativas
Comentários
  • I - Cada incremento do desenvolvimento iterativo gera um produto que já poderá ser utilizado pelo cliente. Portanto, passível de sofrer o teste do sistema (teste do conjunto). Alem do teste do sistema temos testes unitários e testes de interação. Lembre-se também que no desenvolvimento por prototipagem, os protótipos parciais não são usáveis. São por exemplos, telas sem métodos associados (só a casca :))II-O teste descrito é o teste de estresseII-Os testes também são úteis para comprovar que o software faz aquilo que deve ser feito.
  • De acordo com Sommerville 8a edição cap. 23:

    Item I:
    O teste de sistema envolve a integração de dois ou mais componentes que implementam funções ou carac-terísticas do sistema e depois o teste desse sistema integrado. Em um processo de desenvolvimento iterativo, o teste de sistema concentra-se no teste de um incremento que será entregue ao cliente; em um processo em cascata, o teste de sistema concentra-se no teste de todo o sistema.

    Item II:
    Os testes de desempenho devem ser projetados para assegurar que o sistema pode operar na carga necessária. Isso envolve, geralmente, o planejamento de uma série de testes em que a carga é constantemente aumentada até que o desempenho se torne inaceitável.

    Item III:
    Conforme expliquei no Capítulo 22, o processo de teste de software tem duas metas distintas:
    1. Demonstrar ao desenvolvedor e ao cliente que o software atende aos requisitos. (..)
    2. Descobrir falhas ou defeitos no software que apresenta comportamento incorreto, não desejável ou em não conformidade com sua especificação. (..)
  • a) I apenas


ID
120688
Banca
FCC
Órgão
SERGAS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Embora o processo de desenvolvimento de sistemas não esteja previsto na UML, podem-se eleger, em termos genéricos, cinco etapas em que a UML pode ser aplicada: análise de requisitos, análise sistêmica, projeto, implementação, testes/implantação. A etapa de testes/implantação deve abordar os testes de

I. unidade, onde cada programa, individualmente, é testado.

II. conjunto, pois nada garante que, apesar de terem funcionado individualmente, eles se comportarão da maneira esperada, quando executados em conjunto.

III. integração, quando o software criado tiver algum mecanismo de interface com outros sistemas.

IV. adequação aos requisitos, com o envolvimento direto do usuário, que dará a aprovação final.

Está correto o que se afirma em

Alternativas
Comentários
  • Teste de unidade

    Também conhecida como teste unitário ou teste de módulo, é a fase em que se testam as menores unidades de software desenvolvidas (pequenas partes ou unidades do sistema).[9] O universo alvo desse tipo de teste são as subrotinas ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo.

    http://pt.wikipedia.org/wiki/Teste_de_software
     

  • Uso bizarro de termos nessa questão.
  • Questão bizarra mesmo.
    Até cogitei a d (II,II,IV), mas considerar que a granularidade de um teste de unidade é um programa é muito errado...

  • Generalizar teste de unidade com programa completo é forçar a barra. Eu marquei a letra D.

    O teste de unidade consiste em teste caixa-branca e que aborda a menor unidade de um programa. Muitas vezes são testados fluxos de execuções de um método. Esta abordagem pode ser percebida utilizando-se o framework Junit.

    Achei bisonho atribuir a um programa completo o teste de unidade. Isso estaria correto se fosse o teste de sistema. Estranho esta questão não ter sido anulada.

  • Pra que colocaram a opção III? Em todas as opções ela aparece como verdadeira....

    O cara tava muito louco quando fez essa questão!

  • Invenção de conceitos à revelia.

  • Horrível escolha de termos. Aí o candidato lê e fica pensando se o examinador quis confundir ou se é apenas para analisarmos o conceito geral.

  • Gente, vocês estão mesmo estudando pela Wikipédia? E outra: uma unidade ou módulo é um programa sim. Se resolve um problema, é um programa.

  • Fonte que o examinador usou para a questão: Arial, 12


ID
126511
Banca
ESAF
Órgão
Prefeitura de Natal - RN
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Quanto aos princípios básicos da Engenharia de Software, é correto afi rmar que

Alternativas
Comentários
  • Pôxa, não é a letra C ? A letra B não seria referente a testes de caixa branca ?
  • Também marquei letra C. Concordo com você e ainda acredito que a gestão de projetos engloba todo o processo de desenvolvimento de software. Qual etapa não entra???

  • (É OSSO... "Comentário RUIM"... E eu mané ainda insisto em comentar ) 

    "O método de teste de Caixa Preta concentra-se na estrutura de controle do projeto procedimental para derivar casos de teste."


    FALSO. A técnica de teste caixa preta deriva seus casos de teste a partir dos requisitos funcionais do software ( Executar todos os requisitos funcionais de um programa )

    "EXECULTAR TODAS AS FUNCIONALIDADES"

    --

    "uma das técnicas para elaboração de casos de teste da caixa preta é a garantia de que todos os caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez. "

    ERRADO.  Os testes caixa-branca é que possibilitam a execução de todos os caminhos independentes dentro de um programa, para isso contamos com a complexidade ciclomática, que é calculada pelas fórmulas:

    i) V(G) = (E - N) + 2 ou  ii) então V(G) = P + 1

    Em i) temos E como sendo o número de arestas do grafo (Edges) e N como o número de vértices ( Nodes ).

    Em ii) temos P como sendo o número de nós preditivos ( condicionais ).

    --- EXEMPLO --

    http://www.questoesdeconcursos.com.br/images/provas/270/Imagem%20022.jpg

    A complexidade ciclomática desse método seria 

    if ( x == 1 || x == 2) , temos 2 condições então P=2

    o for também é uma condicional, como uma condição de teste apenas, então atualizamos nosso P.    P=3

    O if dentro do for é mais uma condição, então vamos para P=4.

    V(G) = 4+1, V(G) = 5.

    ( Mais Detalhes) http://www.questoesdeconcursos.com.br/questoes/3f2fffc6-6c?tab=2

    -------------------------

    "quando um projeto de software é planejado, a estimativa de esforço humano e a duração do cronograma do projeto são duas das atividades que só podem ser executadas após a implantação do produto. "

    FALSO. Existem muitas métricas para estimar esforço humano como COCOMO, baseado em análise de esforço por pontos de função e etc.

    -------------------------


    "A análise de sistemas é uma atividade que só pode ser iniciada após o estabelecimento das restrições de prazo e de custo do projeto. "

    FALSO. A Análise cobre todas as fases, da especificação dos requisitos à implantação, ao contrário do programador que concentra seus esforços na implementação, testes e implantação.

  • a) o método de teste de Caixa Preta branca concentra-se na estrutura de controle do projeto procedimental para derivar casos de teste.

    b) uma das técnicas para elaboração de casos de teste da caixa preta branca é a garantia de que todos os caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez.

    d) quando um projeto de software é planejado, a estimativa de esforço humano e a duração do cronograma do projeto são duas das atividades que só podem ser executadas após a implantação do produto.
    São executada durante o planejamento.

    e) a análise de sistemas é uma atividade que só pode ser iniciada após o estabelecimento das restrições de prazo e de custo do projeto.
    Não.

ID
126514
Banca
ESAF
Órgão
Prefeitura de Natal - RN
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação aos tipos de testes que podem ser considerados e executados em um projeto de software, é correto afi rmar que o objetivo principal do Teste Funcional é assegurar que

Alternativas
Comentários
  • Discordo com o gabarito, pois o correto seria a letra D
  • Não sei pq discorda, pra mim está totalmente correto

  • Digam o porque e as fontes das respostas.. dizer que sim porque sim nao acrescenta nada !
  • Teste Funcional = Requisitos Funcionais (o que o sistema faz , houve uma correta implementação dos requisitos solicitados)
    As outras opçãos são referentes a Não funcionais.
    • a) a interface forneça ao usuário o acesso e a navegação adequados através das funções do software. TESTE DE USABILIDADE
    • b) os objetos contidos na interface funcionam conforme o esperado e estejam em conformidade com padrões estabelecidos. "PADRÕES ESTABELICIDOS" REMETE A TESTES DE PERFORMANCE
    • c) foram exercitados um conjunto de funcionalidades para avaliar a navegação pelo software e a facilidade de uso do mesmo.TESTE DE USABILIDADE
    • d) houve uma correta implementação dos requisitos do sistema, como, por exemplo, regras de negócio, através da interface do usuário.TESTES FUNCIONAIS
    • e) foram executadas transações, variando as cargas de trabalho, para observar e registrar o comportamento do sistema. "VARIANDO AS CARGAS DE TRABALHO" REMETE A TESTE DE PERFORMANCE

ID
128410
Banca
FCC
Órgão
TRT - 15ª Região (SP)
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Os testes de integração têm por objetivo verificar se

Alternativas
Comentários
  • C) CORRETOcomentando as erradas:A) um módulo geralmente contém e engloba as funcionalidades das unidades que o compõe, e há de se esperar que os resultados sejam diferentes, ou mais completos, do que se fizéssemos os testes individualmente;B) refere-se a testes de carga;C) testes de caixa branca ou caixa preta, e de regressão;E) testes de desempenho.
  •  de acordo com a wikipédia:

    Na fase de teste de integração, o objetivo é encontrar falhas provenientes da integração interna dos componentes de um sistema. Geralmente os tipos de falhas encontradas são de transmissão de dados. Por exemplo, um componente A pode estar aguardando o retorno de um valor X ao executar um método do componente B; porém, B pode retornar um valor Y, gerando uma falha. Não faz parte do escopo dessa fase de teste o tratamento de interfaces com outros sistemas (integração entre sistemas). Essas interfaces são testadas na fase de teste de sistema, apesar de, a critério do gerente de projeto, estas interfaces podem ser testadas mesmo antes de o sistema estar plenamente construído.

    sendo assim, não parece mais coerente a resposta A?

     

  • Tendo em vista que as duas únicas alternativas que causam problemas, dado sua similaridade, são a letra A e C vou comentá-las:

    A) Um módulo não pode apresentar o mesmo resultado que suas unidades testadas individualmente, até porque esses resultados individuais serão computados pelo módulo que irá apresentar seu próprio resultado. O que podemos entender de forma errônea é que os módulos precisam apresentar resultados corretos assim como as unidades apresentam resultados corretos, mas não é isso que a alternativa nos apresenta.

    C) Se um módulo é testado e apresenta os resultados sem nenhum erro podemos dizer que esse módulo atende aos requisitos de sua responsabilidade.

  • Não seriam os testes de validação que testariam a conformidade com os requisitos??
  • "As funcionalidades dos módulos testados atendem aos requisitos" não seriam testes de unidades?
  • "O teste de integração é uma técnica para descobrir erros associados com as interfaces"
    Pressman, 7ed, pag 409


    O mais triste de tudo é ver gente confirmando essas presepadas da FCC através de wikipedia........
  • Teste de integração é uma tecnica sistemática para construir a arquitetura do software enquanto, ao mesmo tempo, conduz testes para descobrir erros associados as interfaces. Pressman, 6 ed. p. 297

    Teste de Validação: A validação do software e conseguida por intermédio de uma série de testes que demonstram conformidade com os requisitos. Pressman, 6 ed. p. 304

    O sentido de interface do Pressman são as intefaces dos módulos que estão sendo integrados. A letra C tem mais a ver com teste de validação.

    Para mim é a letra A.
  • A verdade é  que não existe concenso nenhum entro os autores, cada um utiliza a nomenclatura que bem entender e alem disso definem testes com nomes diferente para confundir nossa cabeça. Esse assunto deveria ser  estudado por apenas uma bibliografia e a banca deveria definir isso no edital, eh um absurdo oque os examinadores fazem com essa "margem" que as bancas dão, parece um circo, cada um utilizando a referência que quiser. 

    Enquanto Sommerville define testes de componentes, Pressman trata do mesmo teste com outra nomenclatura - teste de integração - ... Sommerville define testes de usuário ( alfa, beta e de aceitação , alfa - usuarios junto com desenvolvedores em sistema em desenvolvimento, beta - quando release antecipado é disponibilizado para o cliente ) enquanto Pressman diz que os testes alfa e beta são testes de aceitação. Pelo menos aqui ambos falam em testes de usuário.  Sommerville define testes de sistemas da seguinte maneira: " Teste de sistema, em que alguns ou todos os componentes de um sistema estão integrados e o sistema é testado como um todo. O teste de sistema deve centrar-se em testar as interações entre os componentes". Com essa definição é muito fácil vc se confundir com os testes de integração definidos pelo Pressman.

    No quesito Verificação e validação então a confusão é geral. Segundo Sommerville o primeiro está relacionado com a eficácia e o segundo com a eficiência. O primeiro é mais geral e verifica se o software atendeu as necessidades do cliente, ou seja, se construiu o produto certo , enquanto que o segundo fala em atendimento dos "requisitos não funcionais" dos usuário, ou seja, se o produto atende as exigencias de perfomance, confiabilidade e etc,  logo, eficiencia. Por isso, DISCORDO do comentário anterior que diz que a VALIDAÇÂO é o atendimento dos requisitos.... acho que seria mais adequado falar em atendimento das necessidades dos usuários ou em eficácia..  e para fechar, temos um show de testes de performance, que pelo ponto de vista do Sommerville, este trata como "teste de desempenho" e dentro desta categoria ainda fala do teste de estresse, ou seja, o teste de estresse é um tipo de teste de desempenho.. Já o Presman entende que todos são subitens dos testes de sistemas. Dentro dessa categoria temos, (i) testes de recuperação, (ii) testes de segurança, (iii) teste de estresse e (iv) testes de desempenho, ou seja, na visão deste autor o teste de estresse é um e o de desempenho é outro. Este último tem o objetivo de testar o sitema em execução enquanto o primeiro é de levar o sistema ao limite e evidenciar falhas...  enfim, 

    tudo isso que eu citei geram uma série de dúvidas e ambiguidades. Sem dúvida as limitações da nossa liinguagem atrapalham e muito dificultando bastante. Enfim, minha dica é que estudem por ambos, tentem pegar as nuâncias de cada tipo de teste e deêm sim uma olhada na wikipedia antes da prova pois la tem um apanhado geral dos principais testes e o bom é que tem conceitos dos vários autores. 

    Quanto a questão, concordo com o gabarito.

    Abcs

  • Simplesmente as duas questões estão certas, pois conforme comentaram, não existe convergência de ideias sobre os autores, porém se analisar bem, a questão C está mais correta do que a questão A.
  • Na alternativa C ele diz que produz o mesmo resultado que as unidades testadas individualmente. Na verdade se obtém o resultado esperado e não o mesmo resultado que é obtido no componente e um  módulo. (não necessariamente o mesmo resultado, se a referência for um valor de saída por exemplo). Portanto a alternativa "C" não resta dúvidas quanto a sua aplicabilidade.


ID
128827
Banca
FCC
Órgão
MPE-SE
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

A execução de um sistema com o objetivo de encontrar falhas sob condições que demandam recursos em quantidade, frequência ou volume anormais é definida como

Alternativas
Comentários
  •  É extremamente importante saber diferenciar os testes, principalmente os que possuem um conceito aparentemente próximo com outros. A exemplo disso temos os testes de desempenho, de carga e de estresse:

    - Teste de desempenho: busca extrair informações sobre o desempenho do sistema em cenários normais de uso;

    - Teste de carga: busca extrair informações sobre o volume de usuários, transações, etc o sistema suporta;

     - Teste de stress: busca extrair informações sobre quando o sistema não suporta a carga aplicada, sendo muito importante para saber estruturar e dimensionar a arquitetura do sistema e prover informações para escalar o sistema.

     

    [1] http://qualidadebr.wordpress.com/2010/08/29/teste-de-desempenhocargastress/

  • b-

    teste de stress - condições extremas e volumes grandes

    teste de performance - normal


ID
133999
Banca
CESPE / CEBRASPE
Órgão
CEHAP-PB
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação a técnicas e estratégias de validação para desenvolvimento de sistemas, assinale a opção correta.

Alternativas
Comentários
  •  A) está falando dos testes Beta

    B) O erro está no final quando ele fala que não se aplica a sistemas de cliente únicos

    C) ok

    D) Revisão Técnica Formal

  • Segundo Pressman (6ª edição - página 304), testes alfa e beta somente são utilizados quando o sistema é desenvolvido para ser utilizado por múltiplos clientes. No caso de um único cliente, utiliza-se o teste de aceitação. Portanto, o erro da alternativa "a" está em afirmar que o teste alfa é conhecido como teste de aceitação. O conceitos são diferentes.
  • A alternativa B foi retirada do Sommerville (7ª edição), e não do Pressman.
    Vamos ao trecho do livro:

    "O teste de aceitação é algumas vezes chamado de teste alfa. Os sistemas sob encomenda são desenvolvidos para um único cliente. O processo de teste alfa continua até que o projetista do sistema e o cliente concordem que o sistema liberado é uma implementação aceitável dos requisitos do sistema.
    Quando um sistema será comercializado como um produto de software, frequentemente é usado um processo de teste denominado teste beta."

    Vamos agora destrinchar a alternativa B:
     - O teste alfa, conhecido como teste de aceitação (correto);
     - encerra-se quando cliente e projetista concordam que o sistema é uma implementação aceitável dos requisitos do sistema (correto);
     - não se aplica a sistemas desenvolvidos para um único cliente (errado). Como podemos ver no trecho do livro, testes alfa se aplicam a sistemas desenvolvidos para um único cliente. Testes beta é que não se aplicam.

  • por que a revisão técnica formal é a mais utilizada? não é o contrário? e o teste caixa-preta tem que ser aplicado no final do processo de teste, não pode ser no meio ou no início?

  • Teste caixa-preta:

    - também chamado de teste comportamental;

    - focaliza os requisitos funcionais de um sistema, com pouca preocupação em relação à estrutura lógica interna do software.

    - tenta encontrar erros nas seguintes categorias:

    (1) funções incorretas ou faltando;

    (2) erros de interface;

    (3) erros em estruturas de dados ou acesso a bases de dados externas;

    (4) erros de comportamento ou de desempenho;

    (5) erros de inicialização e término.

    (Pressman)


ID
137122
Banca
FGV
Órgão
Senado Federal
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Considere as seguintes assertivas sobre o teste de sistema:

I. Teste de mutação é um critério de teste da técnica baseada em defeitos.
II. O tempo médio para falhas (MTTF) pode ser utilizado para medir a confiabilidade do sistema; quanto mais próximo do zero o MTTF, maior a confiabilidade do sistema.
III. No teste funcional não são considerados os aspectos de implementação do software e por isso a técnica é também chamada de caixa-preta.

As assertivas corretas são:

Alternativas
Comentários
  • II. ERRADO porque é MTBF e não MTTF. MTBF é Mean Time Between Failures - TMEF(Tempo Médio Entre Falhas).

    []s
    Bons Estudos
    Marcelo
  • Na verdade, o item II erra em dizer que o MTTF deve ficar próximo do zero. Tanto para o MTTF (tempo médio para falhas), quanto para o MTBF (tempo médio entre falhas), o valor deve ser mais alto, pra indicar maior confiabilidade do sistema.

    MTTFO tempo médio para a falha descreve o tempo esperado para a falha de sistemas não-reparáveis

    Por exemplo, suponha que você testou 3 sistemas idênticos a partir do tempo 0 até que todos eles venham a falhar. O primeiro sistema falhou em 10 horas, a segunda falha ocorreu às 12 horas e a terceira falha ocorreu às 13 horas. O MTTF é a média dos três tempos de falha, que é 11,6667 horas.

  • Teste de mutação? Pelo visto tem mesmo..
    http://tw.gs/XZWdi
  • O item II está errado porque o tempo médio para falhas (MTTF) pode ser utilizado para medir a DISPONIBILIDADE do sistema.
  • É interessante citar que essa métrica é utilizada, por exemplo, nos programas para teste de HD's principalmente. Acertei


ID
142066
Banca
CESPE / CEBRASPE
Órgão
TRE-MT
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Com referência a testes de software, assinale a opção correta.

Alternativas
Comentários
  • Completamente errada. O teste de regressão podem ser realizadas em outras fases. Questão sem opção correta.

  • Concordo com o Bruno, também não achei nenhuma das alternativas corretas.

  • Também errei a questão, não tinha ouvido falar que o teste de regressão era aplicado somente a manutenção do sistema, mas parece que faz algum sentido sim.

    O teste de regressão é uma técnica do teste de software que consiste na aplicação de testes à versão mais recente do software, para garantir que não surgiram novos defeitos em componentes já testados. Se, ao juntar o novo componente ou as suas alterações com os componentes restantes do sistema surgirem novos defeitos em componentes inalterados, então considera-se que o sistema regrediu.

    Nesse caso, a meu ver, o teste de regressão poderia ser aplicado a manutenção realizada com qualquer finalidade: fazer acréscimo de funcionalidade, melhorar desempenho, adaptar o software a um ambiente operacional diferente, ou mesmo corrigir erros encontrados na fase de operação do sistema.

     

  • b) O teste de integração deve ser realizado logo após os testes individuais de unidades, obrigatoriamente por equipes diferentes da equipe de desenvolvimento.

    c) O teste de unidade tem foco na menor unidade de um sistema, um programa um módulo. Testes em funções, procedimentos ou métodos não são considerados testes de unidade.

    d) O teste alfa é conduzido pelo cliente em seu ambiente de uso final.
    - Projetista e cliente participam
    - É simulado o ambiente de produção do cliente
    - É conduzido nas instalações do desenvolvedor com os usuários finais. O desenvolvedor 'olhando' sobre os ombros dos usuários e registrando erros e problemas encontrados.

    e) Testes de sistema não podem explorar requisitos não funcionais.
    O objetivo é executar o sistema sob o ponto de vista do usuário final, varrendo as funcionalidades em busca de falhas em relação aos objetivos.
    Os testes sao executados em condições similares àquelas que o usuári utilizará no seu dia a dia.
    São testados requisitos funcionais e não funcionais.
  • Não consegui identificar uma questão correta.
  • Correta letra (a) :  Segundo Pressman, Cada vez que um novo módulo é adicionado como parte do teste de integração, o software se modifica. Novos caminhos de fluxo de dados são estabelecidos, nova E/S pode ocorrer e nova lógica de controle é acionada. Essas modificações podem causar problemas com funções que previamente funcionavam impecavelmente.... o teste de regressão é a reexecução de algum subconjunto de testes que já foi conduzido para garantir que as modificações não propagassem efeitos coletareis indesejáveis.
  • Por ELIMINAÇÃO, letra A
  • Não entendi a dificuldade que a maioria encontrou.
    O teste de regressão é realizado para garantir que novas funcionalidades não impactarão em defeitos no sistema.
    Ora, novas funcionalidades implica que o sistema não está mais na primeira versão, logo está necessariamente em uma manutenção.
  • Ao meu ver não tem gabarito essa questão, vejo que o pessoal está confundindo manutenção com melhoria...
    Caso sejam feitos reparos no software seria manutenção do software, bug, migração de xp para win 7, atualização de segurança, nada disso acarreta novas funcionalidades.
    Caso sejam realizadas inserções de novas funcionalidades seriam melhorias no software, o software agora além de trazer o resultado também calcula a média.
    Sendo assim, os testes de regressão precisam tanto ser aplicados tanto em softwares que estão sendo ''manutenidos(nunca mais esquecerei dessa palavra graças ao Vitorino) quanto os que estão ''sofrendo'' melhorias. Ou seja NÃO SOMENTE durante a manutenção...
    Nem iria adiantar entrar com recurso pois a banca iria dizer que tudo é manutenção...
    Revisão do carro é manutenção ou melhoria?? E Chipar ele, melhoria ou manutenção ??
  • Leandro, então me responde qual nova funcionalidade é adicionada em uma manutenção corretiva!!!

  • Não tem resposta certa esta questão.

    Segundo Pressmann, o teste de regressão é aplicado no método de integração bottom-up, em desenvolvimento de software novo. A cada integração de um novo módulo, testa-se os já integrados para verificar se nada foi quebrado. Ou seja, não se pode afirmar que o teste de regressão é aplicado somente em manuntenção.

  • O estagiário do CESPE ataca novamente! 

  • Nem por eliminação consegui responder ... Opções absurdas!!! 


ID
142825
Banca
FIP
Órgão
Câmara Municipal de São José dos Campos - SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

O processo de verificação e validação de um software é realizado através de um conjunto de atividades. É correto afirmar que:

Alternativas
Comentários
  • Questão errada mesmo, eu assinei a Letra C, pois era a mais lógica. Mas regressão que eu saiba pode ser feito em qualquer etapa.
  • O que está errado na letra b? Patra mim tanto a C quanto a B estão corretas.
  • a) o papel da verificação validação é assegurar que o programa realiza aquilo que o usuário necessita e atende as suas expectativas.

    b) as atividades de validação verificação examinam se o software atende aos seus requisitos funcionais e não funcionais.
  • c-

    testes é para ver ha erros, e nao se nao ha erros.

    usario valida o software

    analista verifica o software

  • VERIFICAÇÃO: refere-se ao conjunto de tarefas que garantem que o software implementa corretamente uma função especificação.

     - " Estamos criando o produto corretamente?"

    VALIDAÇÃO: refere-se a um conjunto de tarefas que asseguram que o software foi criado e pode rastreado segundo os requisitos do cliente.

     - "Estamos criando o produto certo?"


ID
142861
Banca
FIP
Órgão
Câmara Municipal de São José dos Campos - SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Normalmente, são descobertos defeitos durante o processo de verificação e validação de um software, e os artefatos onde eles estão localizados devem ser modificados para sua correção. Não é correto afirmar que:

Alternativas
Comentários
  • b) ERRADO. Os primeiros trabalhos sobre confiabilidade de software tentaram explorara matemática da teoria da confiabilidade de hardware para a previsão da confiabilidade de software. A maioria dos modelos de confiabilidade relacionada com hardware tem como base falhas devido a desgaste e não as falhas devido a defeitos de projeto. Em hardware, as falhas devido a desgaste físico (por exemplo, os efeitos decorrentes de temperatura, corrosão, choque) são improváveis do que uma falha relacionada ao projeto. Infelizmente, a reciproca é verdadeira para o software. Na realidade, todas as falhas de software podem ser associadas a problemas de projeto ou de implementação, o desgaste não entra em questão.

     

    Fonte: Engenharia de Software - 8ª Edição. Por Roger Pressman, Bruce Maxim


ID
142867
Banca
FIP
Órgão
Câmara Municipal de São José dos Campos - SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Considere as seguintes afirmações:

(1) Programas de computador são obras de engenharia que devem seguir, rigidamente, normas e padrões técnicos.
(2) Uma falha de software pode comprometer a integridade, disponibilidade e confidencialidade de um sistema de informações empresarial.
(3) Os testes de caixa preta são utilizados para demonstrar que as funções do software estão operacionais, que as entradas válidas são adequadamente aceitas e produzem saídas corretas, mantendo a integridade das informações externas.

É correto afirmar que:

Alternativas
Comentários
  •  'seguir, rigidamente, normas e padrões técnicos' é um pouco forte! Quero saber qts. software houses seguem rigidamente normas e padrões técnicos... 

  • A dúvida maior é qual o Engenheiro de Software que fez tal declaração.
  • Putz, seguir rigidamente normas e padrões técnicos... onde se faz isso???
  • é que as palavras "devem seguir" faz toda diferença :)
  • Que diabo de banca ridicula faz uma afirmacao como essa - (1) Programas de computador são obras de engenharia que devem seguir, rigidamente, normas e padrões técnicos.

    Agora temos uma receita de bolo que deve ser seguida por todas empresas, sem modificacoes ou alteracoes....
  • Péssimo, que afirmação mais absurda!!!
  • Essa primeira afirmação só pode ser brincadeira!!! 

     

  • Lixo de questão, igual a banca (que nunca ouvi falar)... A depender da proposta e dimensão do projeto a ser desenvolvido não se faz necessário e verdadeira tal afirmação...

  • Dizer que devem seguir não significa, necessariamente, que na rática, seguem.


ID
143746
Banca
FIP
Órgão
Câmara Municipal de São José dos Campos - SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação à qualidade de software, é incorreto afirmar que:

Alternativas
Comentários
  • Em algumas situações os custos dos testes são maiores que o prejuízo do erro. Nestes casos pode-se validar um software contendo erros.

  • Afirmativa incorreta: Letra C . Os testes não podem garantir que o Software está livre de erros. Logo, não temos que essa garantia que "nenhum erro será encontrado", mesmo com testes exaustivos.

  • O objetivo de qualquer teste é justamente expor os possíveis erros do sistema. Se formos pensar que o objetivo é testar até nenhum erro ser encontrado, podemos simplesmente não fazer nenhum teste que nenhum erro será encontrado e damos o software como validado.

    Gabarito C

    Sobre a alternativa A: se não tivermos testado a condição de erro X, se esta ocorrer durante a execução do programa, teremos uma falha. Com isso, podemos dizer que os testes realmente não podem garantir que não ocorrerá erro na execução de um programa, salvo se prevermos todas as infinitas condições em que o SW estará submetido.


ID
144496
Banca
CESPE / CEBRASPE
Órgão
TRE-MA
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

O teste do software tem a finalidade de fornecer informações acerca da qualidade do software em relação ao contexto em que ele deve operar. Os testes de software incluem a técnica denominada

I caixa preta.
II caixa branca.
III caixa cinza.
IV teste de integração.
V teste de sistema.

A quantidade de itens certos é igual a

Alternativas
Comentários
  •  A questão se refere a TÉCNICAS  de Teste.

    Teste de Integração e Teste de Sistema são Fases do Teste.

    Obs. Questão retirada da Wikepédiahttp://pt.wikipedia.org/wiki/Teste_de_software

  • I, II e III - São as Técnicas de Testes (resposta da questão)

    IV e V - São dois dos quatro Níveis de Testes (os outros dois são teste unitário e de validação)
  • certa é letra d


ID
144826
Banca
CESPE / CEBRASPE
Órgão
INMETRO
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca das relações estabelecidas entre os modelos de ciclo de
vida de software, os modelos de gestão e seus exemplos, julgue
os itens de 62 a 71.

A rotina diária dos desenvolvedores, ao empregar processos baseados no TDD (Test Driven Development), é concentrada na elaboração de testes de homologação.

Alternativas
Comentários
  •  Testes unitários também são o foco.

  • Alternativa errada, a rotina dos desenvolvedores que seguem TDD é baseada na implementação de testes unitários no início do desenvolvimento de cada funcionalidade, após isso inicia-se a codificação da funcionalidade propriamente dita, visando atender aos testes já implementados.
    É claro que os desenvolvedores podem atuar na elaboração de testes de homologação, mas não se pode afirmar que isso faz parte de sua rotina diária.
  • Errado

    O TDD consiste em criar primeiro Testes Unitários e depois o código do programa.
  • A prática TDD envolve primeiramente construir testes antes da implementação de funcionalidades. Dessa forma serão feitos vários testes unitários (para cada nova funcionalidade desenvolve em geral um teste). Portanto o erro da assertiva é dizer que o TDD é concentrado em testes de homologação (quando o produto de software for ser entregue ao cliente).

    Gabarito: E


ID
147280
Banca
FCC
Órgão
SEFAZ-SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Garantir que um ou mais componentes de um sistema combinados funcionam corretamente é o objetivo do tipo de teste

Alternativas
Comentários
  • Resposta letra B

    Teste de integração é a fase do teste de software em que módulos são combinados e testados em grupo. Ela sucede o teste de unidade, em que os módulos são testados individualmente, e antecede o teste de sistema, em que o sistema completo (integrado) é testado num ambiente que simula o ambiente de produção.

    O teste de integração é alimentado pelos módulos previamente testados individualmente pelo teste de unidade, agrupando-os assim em componentes como estipulado no plano de teste, e resulta num sistema integrando e preparado para o teste de sistema.


ID
147283
Banca
FCC
Órgão
SEFAZ-SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

O teste de ameaça normalmente deve ser aplicado dentro de um projeto de software nas etapas de

Alternativas
Comentários
  • Seria o mesmo que teste de penetração?

    A meu ver é um teste semelhante ao teste de segurança porém mais voltado para identificar falhas. Não achei nenhuma referência confiável para este assunto. Quem descobrir o artigo misterioso de onde a FCC copiou/colou esta questão, avise-nos.
  • Nesse caso, teste de ameaça está inserido no contexto de Teste de Segurança. Sabemos que o Teste de Segurança é realizado em 2 momentos: durante o teste de integração, pois nesse momento estamos verificando se os módulos são capazes de trabalharem junto; e no teste de sistemas, onde temos o teste de desempenho, recuperação, segurança e estresse.

  • O máximo que eu encontrei foi uma referência a teste de ameça num TCC ao seguinte livro: "Testes de Software: Produzindo Sistemas Melhores e Mais Confiáveis, Leonardo Molinari, 2003. "

    Se alguém tiver ele pode ser que a resposta esteja no mesmo.
  • no teste de aceitação não seria, pois lembremos da curva onde o custo de correção aumenta à medida que as fases vão progredindo, o custo de se corrigir algo na fase de aceitação seria altissimo
  • Marquei a E, pois levei em consideração a Estratégia de Teste elaborado por pressman

    https://uploaddeimagens.com.br/imagens/estrategia_de_testes_-_pressman-png


ID
147694
Banca
FCC
Órgão
MPU
Ano
2007
Provas
Disciplina
Engenharia de Software
Assuntos

Considere as informações abaixo em relação ao desenvolvimento de sistemas:

I. executar um software com o objetivo de revelar falhas, mas que não prova a exatidão do software.
II. correta construção do produto.
III. construção do produto certo.

Correspondem corretamente a I, II e III, respectivamente,

Alternativas
Comentários
  • Teste -> é um conjunto de atividades que podem ser planejadas antecipadamente e conduzidas sistematicamente. Uma das características do teste é: Um bom teste tem alta probabilidade de encontrar um erro.

    Verificação -> refere-se ao conjunto de atividades que garante que o software implementa corretamente uma função específica.

    Validação -> refere-se a um conjunto de atividades diferente que garante que o software construído corresponde aos requisitos do cliente.

    Fonte: Pressman - 4ª edição.
  • Barry Boehm, pioneiro da engenharia de software, expressou sucintamente a diferença entre validação e verificação
    (BOEHM, 1979):


    • 'Validação: estamos construindo o produto certo?'
    • 'Verificação: estamos construindo o produto da maneira certa?'

  • c-

    Requisitos sao validados, o software é verificado.

  • Verificação está mais relacionado ao modo de construir o sistema. tais como: metodologias, linguagens etc.Ou seja, se refere a maneira de desenvolver o sistema.
    Validação está relacionado se os requisitos do sistema estão aderentes ao acordado com os clientes.Pode acontecer de fazer uma verificação eficiente em um sistema, ou seja, o mesmo foi produzido conforme planejado, mas na hora de entregar ao cliente (validação) não era o que este solicitou.

  • Esta resposta está errada, de acordo com o simulado estácio de engenharia de software. A correta seria

    verificação, teste e validação. 


ID
148093
Banca
FCC
Órgão
TRT - 16ª REGIÃO (MA)
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Há um tipo de teste que vislumbra a "destruição do programa" por meio de sua submissão a quantidades, frequências ou volumes anormais que é o teste

Alternativas
Comentários
  • "Em testes de desempenho, isso significa estressar o sistema, fazendo demandas que estejam fora dos limites de projeto do software. Isso é conhecido como ´teste de estresse´. Por exemplo, digamos que você está testando um sistema de processamento de transações que é projetado para processar até 300 transações por segundo. Você começa a testar esse sistema com menos de 300 transações por segundo; então, aumenta gradualmente a carga no sistema para além de 300 transações por segundo. até que esteja bem além da carga máxima de projeto do sistema e o sistema falhe." (Engenharia de Software -  Sommerville - 9a Ed. - Capítulo 8, pg 159)

    "Os testes por esforço (estresse) servem para colocar os programas em situações anormais. (...) O teste por esforço usa um sistema de maneira que demande recursos em quantidade, frequencia ou volumes anormais." (Engenharia de Software - Pressman - 7a Ed - Capítulo 17, pg 419)

ID
149977
Banca
CESPE / CEBRASPE
Órgão
ANAC
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

A respeito dos conceitos relacionados ao desenvolvimento de
sistemas e às metodologias de desenvolvimento de sistemas,
julgue os itens seguintes.

No modelo extreme programming, os testes de software só são realizados na etapa, final de desenvolvimento do software e, somente nessa etapa, os programadores trabalham, obrigatoriamente, em pares, utilizando cada um o próprio computador.

Alternativas
Comentários
  • Programação em Pares (Pair Programming): é a programação em par/dupla num ÚNICO computador. Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Desenvolvimento Orientado a Testes (Test Driven Development): Primeiro crie os testes unitários (unit tests) e depois crie o código para que os testes funcionem.

    Fonte: http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_extrema
  • Se testar é bom, vamos testar toda hora. Levar ao extremo.
  • Extreme Programming inclui uma abordagem de testes que reduz as chances de erros desconhecidos na versão atual do sistema. O desenvolvimento test-first é uma das mais importantes inovações no XP. Em vez de escrever algum código e, em seguida, escrever testes para esse código, você escreve os testes antes de escrever o código. Isso significa que você pode executar o teste enquanto o código está sendo escrito e pode encontrar problemas durante o desenvolvimento.

    Fonte: SOMMERVILLE, Engenharia de Software, 9 Ed., pág 47.

  • Dividindo para conquistar:


    No modelo extreme programming, os testes de software só são realizados na etapa final de desenvolvimento do software (Erro 1: os testes são feitos o tempo todo (ao extremo), até mesmo antes da codificação de cada funcionalidade, já que o XP faz uso do TDD) e, somente nessa etapa, os programadores trabalham, obrigatoriamente, em pares, utilizando cada um o próprio computador (Erro 2: Os programadores trabalham sempre em pares, sendo vinculado apenas um computador para cada dupla de desenvolvedores).


    Bons estudos!


ID
150946
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre testes no Processo Unificado, é correto afirmar que um(a)

Alternativas
Comentários
  • A) Um plano de teste contém um conjunto de classes de testes. Dentro do plano de teste, há os casos de testes, que são os testes esolhidos dentro de uma classe. Quando se escolhe um plano de teste e casos de teste, se está querendo abranger ao máximo o software à procura de erros. Você estará abrangendo os requisitos funcionais e os não-funcionais - como usabilidade, p. ex.

    Assim, a alternativa inverte as definições.

    B) Script de teste: Instruções passo a passo que permitem a execução de um teste. Os Scripts de Teste podem assumir a forma de instruções de texto documentadas e executadas manualmente ou de instruções que podem ser lidas pelo computador para ativar a execução automática do teste.

    C) Não conheço modelos de testes de software, mas somente Estratégias de teste de software (teste unitário, teste de integração e validação).

    D) prova de conceito não é um tipo de caso de teste. Caso de teste, como já dito, vem a ser teste que você aplica ao software. O caso de teste deve especificar a saída esperada e os resultados esperados do processamento. Numa situação ideal, no desenvolvimento de casos de teste, se espera encontrar o subconjunto dos casos de teste possíveis com a maior probabilidade de encontrar a maioria dos erros

    E) CORRETA - A avaliação de um teste de software é baseada na sua cobertura dos requisitos e casos de teste - ou seja, erros encontrados - ou pela cobertura do código.
  • Só completando a resposta de Wilson:

    Prova de conceito é um documento arquitetural. O nome completo é 'Prova de conceito arquitetural'.
    Esse artefato é criado para determinar uma solução para requisitos críticos. Pode ser dispensado quando os riscos são considerados baixos.

    Ou seja, nada a ver com testes.
  • Retificando a Letra A que comentei...

    Um plano de teste se encontra dentro da estratégia de teste. O plano de teste tem as classes de teste que serão executadas. Algumas classes de testes são teste unitário, teste de integração e teste de sistema. Dentro de cada classe há os casos de teste. Por exemplo, uma classe de teste unitário tem casos de teste ue executa os caminhos independentes do módulo, a sua interface, sua estrutura de dados interna, o fluxo de controle, dentre outros.

    Assim, um plano de teste tem classes de teste que têm casos de teste, tudo dentro de uma estratégia de teste.

  • Complementando a letra B...

    Script de teste vem a ser a estratégia de teste que comentei rapidamente na letra A.
  • FLUXO DE TESTE
    Principal proposito do fluxo de teste é realizar vários teste e sistematicamente analisar os resultado de cada teste
    Verificar se os resultados do fluxo de implementação cumprem os requisitos estipulados p/ cliente e usuários.
     
    MODELO DE TESTE
    É a principal ATIVIDADE
    Descreve como os teste de integração e de sistema exercitarão componentes executáveis a partir do modelo de implementação.
     
    CASO DE TESTE
    Conjunto de entradas, condições de execução e resultados esperados.
    Juntos identificam a finalidade de avaliar um determinado aspecto de um item de teste-alvo
     
    PLANO DE TESTE
    Definição das metas e dos objetivos dos testes no escopo
     
    SCRIPT TESTE
    Conjunto de instruções passo a passo que permitem a execução de um teste.
     
    PROVA DE CONCEITO
    É a prova de uma teoria, que só existia no papel
     
    AVALIAÇÃO DE TESTE
    É a avaliação dos resultado de um conjunto de testes.

ID
151870
Banca
FCC
Órgão
TRE-PI
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Também conhecido por teste estrutural ou orientado à lógica, é uma técnica de teste de software que trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos, tais como, teste de condição, teste de fluxo de dados, teste de ciclos e teste de caminhos lógicos. Trata-se da técnica de teste

Alternativas
Comentários
  • Fonte: http://pt.wikipedia.org/wiki/Teste_de_software

    Caixa-branca:

    Também chamada de teste estrutural ou orientado à lógica, a técnica de caixa-branca avalia o comportamento interno do componente de software. Essa técnica trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos, teste de caminhos lógicos, códigos nunca executados.

  • Engenharia de Software - Teste de Software - Teste de Caixa Branca - Teste Caixa de Vidro Teste Comportamental - Teste Estrutural - Estrutura Interna - Logica do Programa - Decisoes Logicas

  • Gabarito A

    Essas técnicas de Teste se dividem entre Funcional e Estrutural, sendo que o Teste Funcional, ou Teste de Caixa Preta (Black Box), é aquele que tem como alvo verificar se a implementação está de acordo com o que foi especificado. Já o Teste Estrutural, também chamado de Teste de Caixa Branca (White Box), busca garantir que o software desenvolvido esteja bem estruturado internamente, portanto, funcionando corretamente.

     

    "Retroceder Nunca Render-se Jamais !"
    Força e Fé !
    Fortuna Audaces Sequitur !
     


ID
153148
Banca
CESPE / CEBRASPE
Órgão
TJ-DFT
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir, acerca da qualidade e da maturidade em
projetos de software.

A eficiência na remoção de defeitos (defect removal efficiency) é uma métrica específica da fase de testes de um projeto de software que permite avaliar tanto a capacidade de testar da equipe quanto os erros deixados no software durante as fases anteriores, inclusive a especificação, a análise e a codificação.

Alternativas
Comentários
  • Uma métrica de qualidade é a eficiência na remoção dos defeitos (DRE)

    Para o projeto todo a DRE é definida como:

    DRE=E/(E+D)

    E – quantidade de erros encontrados
    D – Quantidade de defeitos

    O valor ideal de DRE é 1, ou seja, nenhum defeito é encontrado no software. As atividade de DRE devem ser realizadas ao longo de cada etapa da Eng. Software

  •  Creio que o erro está em afirmar que DRE é uma métrica específica da fase de testes.

    Fonte: Pressman

  • O erro da questão não está na descrição da métrica em si, e sim na afirmação "específica da fase de testes de um projeto de software".

    Ora, as fases que compõem um projeto de software são: Levantamento de Requisitos; Análise; Projeto (ou Design); Implementação; e Manutenção pós-entrega.

    Os testes, estão presentes em todas estas fases de um projeto de software com características peculiares para cada fase, inclusive em relação ao tempo gasto com os testes em cada fase (tempo de testes gasto na Análise é menor do que o gasto na Implementação).

    Assim sendo, a afirmação está errada por considerar que os Testes representam uma fase de um projeto de software. Na verdade, os Testes são somente uma disciplina e não uma fase (estão presentes ao longo de todo o projeto de software).

    PS: Não confundir Modelos (Cascata, Iterativo e Incremental, Evolutivo, etc) com as fases de um projeto de software.

  • Para mim o erro desta questão está em : "capacidade de testar da equipe".

    Se eu já tenho uma equipe de testes, a mesma não é capacitada ? 

    Por que essa métrica avaliaria a capacidade da equipe ?
  • Segundo Pressman (7ed, pg 595), "Uma métrica de qualidade que traz benefícios tanto para o projeto quanto para o processo é a eficiência na remoção de defeitos (defect removal efficiency - DRE). Essencialmente, a DRE é uma medida da habilidade de filtragem das ações de garantia de qualidade e controle quando elas são aplicadas através de todas as atividades da estrutura de processo. (..) Se for usada como uma métrica que fornece um indicador da habilidade de filtragem das atividades de controle de qualidade e segurança, a DRE estimula a equipe de projeto de software a instituir técnicas para encontrar o maior número possível de erros antes da entrega do software. A DRE também pode ser usada no projeto para avaliar a habilidade de uma equipe para encontrar erros antes que eles passem para a próxima atividade na estrutura do software ou para a próxima ação da engenharia de software."

  • A eficiência na remoção de defeitos (defect removal efficiency) é uma métrica específica da fase de testes de um projeto de software (ERRADO - segundo o RUP teste não é uma fase de um projeto de SW, mas sim uma disciplina que está presente em todas as fases do projeto de SW) que permite avaliar tanto a capacidade de testar da equipe quanto os erros deixados no software durante as fases anteriores, inclusive a especificação, a análise e a codificação


    Bons estudos!


ID
153160
Banca
CESPE / CEBRASPE
Órgão
TJ-DFT
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir, acerca da qualidade e da maturidade em
projetos de software.

Uma matriz de grafo de fluxo de um programa é uma ferramenta que permite a concepção de casos de teste considerando a importância relativa dos percursos possíveis na estrutura do software.

Alternativas
Comentários
  •  Matrizes de Grafos é uma matriz quadrada de nós do grafo de fluxo
    
    Linhas e Colunas > Nó identificado.
    
    Entradas na matriz > Arestas entre nós.
    
    Permite a mecanização da determinação de um conjunto de caminhos básicos

  • Segundo Pressman, uma matriz de grafo e uma ferramenta muito útil para assistir os testes. Adicionando um peso de ligação a cada entrada da matriz, a matriz matriz de grafo pode tornar-se uma possante ferramenta para avaliar a estrutura de controle do programa durante o teste.


ID
156988
Banca
CESPE / CEBRASPE
Órgão
TRT - 5ª Região (BA)
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação a engenharia de software, processos de software, análise de requisitos, estratégias de validação e ferramentas CASE, julgue os próximos itens.

Entre os tipos de testes de caixa preta, encontram-se o teste baseado em grafos; o particionamento de equivalência; a análise de valor-limite; e o teste de matriz ortogonal.

Alternativas
Comentários
  • Note que são testes basedos em entradas e saidas. Não está se analisando codigo fonte. Portanto, Caixa Preta.
  •  Tipos de Teste de Caixa-Preta (Back-Box)

    • Graph-Based Testing Methods
    • Equivalence Partitioning
    • Boundary Value Analysis
    • Orthogonal Array Testing

    Fonte: Pressman (7ª Edição)


ID
157825
Banca
FCC
Órgão
METRÔ-SP
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Um critério de teste de software baseado no fluxo de dados de aplicação pode ser utilizado como uma técnica de teste baseada

Alternativas
Comentários
  • A técnica de teste de caixa-branca também chamada de teste estrutural ou orientado à lógica, avalia o comportamento interno do componente de software. Essa técnica trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos, teste de caminhos lógicos, códigos nunca executados.

    Fonte: http://pt.wikipedia.org/wiki/Teste_de_software
  • O método de teste de fluxo de dados seleciona caminhos de teste de um programa de acordo com a localização das definições e dos usos das variáveis no programa.

    Fonte: Pressman - 6ª edição - pág.325

ID
158995
Banca
CESPE / CEBRASPE
Órgão
STJ
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

No referente a técnicas e estratégias de verificação e
validação, julgue os próximos itens.

Uma abordagem para o projeto de casos de teste consiste em identificar as partições de equivalência. Uma partição de equivalência de entrada contém conjuntos de dados que são processados de modo equivalente. No teste estrutural, que é outra estratégia para projetar casos de teste, se usa o conhecimento da estrutura do programa. O teste de caminho é um teste estrutural no qual se procura exercitar os caminhos percorridos ao se executar o programa.

Alternativas
Comentários
  • Técnica Estrutural (ou teste caixa-branca)
    Técnica de teste que avalia o comportamento interno do componente de software . Essa técnica trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos e teste de caminhos lógicos (PRESSMAN, 2005)
    Teste de Caminho Básico
    O método de caminho básico permite ao projetista de casos de tese originar uma medida da complexidade lógica de um projeto procedimental e usar essa medida como guia para definir um conjunto básico de caminhos de execução. Casos de testes derivados para exercitar o conjunto básico executam com garantia cada comando do programa pelos menos uma vez durante o teste.


ID
162925
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Uma das principais atividades do processo de teste de um ciclo de vida de um projeto qualquer é

Alternativas
Comentários
  • Durante o ciclo de vida do projeto é necessária a criação de documentos de testes, rotinas de testes e em alguns casos é necessária a criação de sistemas teste automático afim de que não se perca horas e esforço humano para tal serviço.
  • a) projetar testes que tratem da especificação de procedimentos externos ao computador, tais como: captação das informações, identificação das partes interessadas e distribuição das saídas.
    ERRADO - Os testes devem ser projetados visando as funcionalidades do próprio sistema, e não o que acontece externamente a ele. Além disso captação das informações, identificação das partes interessadas e distribuição de saídas não fazem parte do processo de testes.

    b) projetar o processo de teste criando casos de teste, rotinas de teste e, eventualmente, desenvolvendo programas que fazem o teste de forma automática.
    CERTO - Estas são as principais tarefas do processo de testes. O desenvolvimento de programas que realizam o teste de forma automática é especialmente importante para a realização de testes de regressão.

    c) analisar e definir testes através da manipulação de ferramentas de processos usadas especialmente para obtenção de requisitos de teste de software, tais como: CMMI, BPM e ISO 9001:2000. 
    ERRADO - O processo de testes utiliza Ferramentas de Testes, e não de processos. CMMI, BPM e ISO são não são usados para obtenção de requisitos de teste. Em resumo, CMMI é um modelo de referência para processos, BPM é uma metodologia para modelagem e melhoria de processos e a ISO 9001:2000 é a norma que define um sistema de gestão da qualidade para as empresas.

    d) produzir testes e o manual de especificação do uso do sistema que é utilizado para ensinar o usuário a manipular o produto final do software.
    ERRADO - O RUP fala que o manual do usuário "pode ser escrito por escritores técnicos, com a colaboração de desenvolvedores, ou pode ser escrito pela equipe de teste, cujos membros provavelmente compreendem a perspectiva do usuário". O que invalida a questão é que esta não é uma das atividades principais do processo de testes.

    e) testar as unidade de software na fase de operação e manutenção do sistema e utilizar os resultados como métricas para eventuais ajustes em projetos anteriores.
    ERRADO - Os testes unitários devem ser realizados pelos desenvolvedores durante a fase de implementação, e não na fase de operação e manutenção.
  • Solange, gostei da sua resposta porém BPM não é Metodologia.


    Metodologia está ligado a uma prescrição (detalhada) de atividades a serem feitas para chegar num determinado objetivo. 


    BPM é uma disciplina gerencial que integra estratégias e objetivos de uma organização com expectativas e necessidades de clientes, por meio do foco em processos ponta a ponta.


    Na página 54 do BPM CBOK v3 está explícito:

    2.2.2 BPM não é uma prescrição de estrutura de trabalho, metodologia ou conjunto de ferramentas



ID
163660
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Testar é uma disciplina de suma importância para a engenharia de software. A literatura divide os tipos de testes em duas grandes categorias: teste de caixa preta e teste de caixa branca. Sobre esta classificação, pode-se afirmar que

I - testes de interfaces são classificados como de caixa branca;

II - testes de caixa preta são também chamados de teste comportamental, onde o foco são os requisitos funcionais do software;

III - testes de caixa preta são complementares aos testes de caixa branca, uma vez que contemplam diferentes classes de erros.

É correto o que se afirma em

Alternativas
Comentários
  • Em suma, teste de caixa branca são os testes internos do software, diretamente no código fonte, como testes no fluxo de dados, testes de condição, etc.Os de caixa preta, entretanto, são os externos ao software. Ou seja, são os testes de aceitação, onde colocamos os dados de entrada e comparamos se a saída está de acordo.I - testes de interfaces são classificados como de caixa branca; Errada. Esse é o teste de caixa preta.II - testes de caixa preta são também chamados de teste comportamental, onde o foco são os requisitos funcionais do software;Correto. O foco desse teste, é verificar se o sistema atende aos requisitos.III - testes de caixa preta são complementares aos testes de caixa branca, uma vez que contemplam diferentes classes de erros.Correto. Os testes de caixa preta abrangem classes diferentes dos de caixa branca.Letra d.
  • I - testes de interfaces são classificados como de caixa branca; (Errada, pois os testes de caixa branca procupam-se com o comportamento interno do componente de software

    II - testes de caixa preta são também chamados de teste comportamental, onde o foco são os requisitos funcionais do software; (Correta, os testes de caixa preta basieam-se no comportamento  externo do componente do software, )

    III - testes de caixa preta são complementares aos testes de caixa branca, uma vez que contemplam diferentes classes de erros.(Correto, o teste de caixa branca, avalia o comportmamento interno e o outro avalia o comportamento externo, contemplando diferentes classes de erros).
  • Discordo do gabarito

    A meu ver a única opção correta é a III.
     
    Na opção II, ao se afirmar que o foco são os requisitos funcionais do sw, exclui-se testes de desempenho, de carga e vários outros não-funcionais que são testes de caixa-preta.
     
  • Discordo totalmente da I. Que interface é essa? Interface de um componente? Se for, em um software convencional, essa é a primeira a ser testada como parte do teste de unidade. Seria assim, parte do teste de caixa-branca.

    É a interface entre componentes, que é testada durante o teste de integração?

    É a interface GUI, que o pessoal está comentando?

    Para mim, apenas II e III corretas.
  • Wilson, tanto pra você, quanto pra Cesgranrio. O gabarito é II e III apenas.
  • Segundo Pressman, "Teste Caixa-Preta, também chamados de teste comportamental, focaliza nos requisitos funcionais do software. As técnicas caixa-preta permitem derivar uma série de condições de entrada que utilizarão completamente todos os requisitos funcionais para um programa. O teste caixa-preta não é uma alternativa às técnicas caixa-branca. Em vez disso, é uma abordagem complementar, com possibilidade de descobrir uma classe de erros diferente daquela obtida com métodos caixa-branca. Diferente do teste caixa-branca, que é executado antecipadamente no processo de teste, o teste caixa-preta tende a ser aplicado durante os estágios posteriores."

    (Fonte: Livro Engenharia de Software, 7ed, Pressman, pág 439)

    I - Errada. Se você vai testar a interface, provavelmente não está interessado na implementação interna desse componente, logo não é caixa-branca.

    Gabarito letra "D".


ID
164647
Banca
FGV
Órgão
BADESC
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

O teste de software que projeta casos de testes derivados do conhecimento da estrutura e da implementação do software é conhecido por:

Alternativas
Comentários
  • Ok. E essa? De onde saui?
    Por analogia deve existir a caixa-escura ao invés de caixa-preta, né?

    Êta provinha ridícula.
    Caixa-branca deveria ser a alternativa correta.
  • Essa questão deveria ser anulada.

    O enunciado cita um teste caixa-branca.

    Considerando que o teste de integração (alternativa e) é o único teste caixa branca, ele deveria ser o correto.

    Lembrando que caixa-claro não existe e uma caixa não pode ser claro, mas sim clara.

  •  Existe sim o termo teste caixa-clara. Segue definição do Ian Somerville, 8 edição, capítulo 23 (testes);

    "O teste estrututal é uma abordagem para projetar casos de teste na qual os testes são derivados do conhecimento da estrutura e da implementação do software. Essa abordagem, é, algumas vezes, chamada de teste "caixa-branca", "caixa de vidro" ou teste "caixa-clara" para distingui-lo do teste caixa-preta.

  •  Se teste caixa-CLAROOOO existe, essa questão deveria ser anulada, porque tanto a anternativa b, quanto a alternativa e estariam corretas.

    Sem falar que não confio nessas traduções de livros americanos.

  •  A alternativa E não está correta. A questão não pede um exemplo de teste caixa-branca. A questão pede um nome para testes caixa-branca.

    Teste de integração é um tipo de teste caixa-branca. Dizer que teste caixa-branca é o mesmo que teste de integração é incorreto.

  • Prezado Colega,

    Ele não pede o nome, mas passa uma idéia geral e apresenta alternativas. Portanto, o teste de integração pode ser uma resposta plausível para a questão.

  • akakkakaka questão engraçada.
    dica pro pessoal:
    Leia a questão....erre, ou acerte....ria um pouco....apague da memória (ou então decore esse termo não usual)....e bola pra frente...finge que nunca viu mais gorda.
  • Teste de integracao eh fase, e não um tipo de conjunto de testes.

    Está certíssima a questão.
  • Um pequeno complemento ao comentário anterior. Testes de Integração é um nível de testes, não um tipo de testes.
    Níveis de testes são: Unitário, Integração, Sistema e Aceitação
    Tipos de Testes: Funcional, Segurança, Desempenho, Volume, Usabilidade, etc... entre vários outros. 
  • Quando eu mostrei essa questao para o professor la do cursinho ele disse que cabia um recurso

    eu disse serio???

    ele disse

    Serio... O recurso que cabe e' estudar mais...

    kkkkkkk

ID
173320
Banca
FGV
Órgão
MEC
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

O teste de software que garante o atendimento aos requisitos, ou seja, que verifica se os requisitos estão corretamente codificados, são conhecidos como:

Alternativas
Comentários
  •  Retirado do Somerville, capítulo 23 (Testes):

    "O Sistema é tratado como uma caixa-presta, cujo o comportamento pode ser somente determinado por meio do estudo de suas entras e saídas relacionada. Outro nome para isso é teste funcional, pois o testado concentra-se na funcionalidade, e não na sua implementação"

     

     

  • Discordo do gabarito pelo seguinte: acho que essa parte de "corretamente codificados" descaracteriza o teste funcional, pois este está preocupado apenas com entradas e saídas e "não se preocupa com a implementação", exatametne como mencionado por Sommerville.

  • Eu concordo com o Rodrigo. Acho que a questão acabou ficando mal formulada para ter como gabarito o teste funcional/caixa preta. Eu errei a questão achando que seria teste de conformidade.

    Vejam esse link: http://www.inpe.br/atifs/html/teste_de_conformidade.htm 

    Não seria isso ai?

  • Concordo que a questão está mal formulada. Tempo de resposta, por exemplo, é um requisito não verificável no teste funcional.
  • Concordo com o gabarito, apesar de também ter ficado entre as alternativas a e d.

    O que me fez decidir pela D foi exatamente o trecho "os requisitos estão corretamente codificados"
    Entendi que ao fazer isso está verificando se os requisitos foram implementados conforme especificados (verificação).
    Já o teste de conformidade entendi que seria verificar se realmente os requisitos especificados correspondem ao que foi pedido pelo cliente (validação).
  • Trata-se de verificação, portanto são testes de caixa-preta ou funcionais.
    Mesmo a questão trazendo a expressão "estão corretamente codificados"  - o que pode trazer confusão com testes caixa-branca - não é o caso. Testes de caixa-branca também são chamados de estruturais, seria impossível marcar 2 alternativas.
  • Muitos achismos somente para justificar o gabarito. Um exemplo de teste foi funcional é o feito com a ferramenta Selenium (para sistemas Web), ele claramente não verifica se o sistema foi codificado corretamente. Tentar justificar isso é meio sem sentido.
  • Olha,

    Para mim, a resposta correta seria Teste Caixa-Branca ou Teste Estrutural devido ao trecho "corretamente codificados".

    Mas como não dá para marcar duas alternativas e a a) e b) não fazem muito sentido então chutei d) Teste Funcional pensando na comida de bola da banca e acabei acertando.

    Mas francamente, esse gabarito está errado, pois isso é um Teste Caixa-Branca ou Estrutural.



ID
173329
Banca
FGV
Órgão
MEC
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Analise a citação a seguir.

"Um conjunto de atributos que têm impacto na capacidade do software de manter o seu nível de desempenho dentro de condições estabelecidas por um dado período de tempo."

A Norma que integra os conceitos de ambiente, estratégias e planejamento de testes, é conhecida por:

Alternativas
Comentários
  • a) ISO 12207: Errada.

    A ISO/IEC 12207 é a norma ISO/IEC que define processo de desenvolvimento de software.

    b) ISO 15504: Errada.

    A ISO/IEC 15504, também conhecida como SPICE, é a norma ISO/IEC que define processo de desenvolvimento de software. Ela é uma evolução da ISO/IEC 12207 mas possui níveis de capacidade para cada processo assim como o CMMI.

    c) ISO 9126: Correta!

    ISO/IEC 9126 é uma norma ISO para qualidade de produto de software, que se enquadra no modelo de qualidade das normas da família 9000. A norma brasileira correspondente é a NBR ISO/IEC 9126. A norma 9126 se foca na qualidade do produto de software, propondo Atributos de Qualidade.

    d) IEEE 829: Errada.

    IEEE 829-1998,[1] também conhecido como o Padrão 829 para Documentação de Teste de Software,[2] é um padrão IEEE que especifica a forma de uso de um conjunto de documentos em oito estágios definidos de teste de software, cada estágio potencialmente produzindo seu próprio tipo de documento.[1][2] O padrão especifica o formato desses documentos mas não estipula se todos eles devem ser produzidos, nem inclui qualquer critério de conteúdo para esses documentos.

     

    e) MPS.BR: Errada.


    O MPS.BR ou Melhoria de Processos do Software Brasileiro é simultaneamente um movimento para a melhoria da qualidade (Programa MPS.BR) e um modelo de qualidade de processo (Modelo MPS) voltada para a realidade do mercado de pequenas e médias empresas de desenvolvimento de software no Brasil.

  • Este é o conceito de confiabilidade, segundo a norma 9126.
    Lembrando dos atributos para enriquecer o conhecimento: FUCEMP
     
    Funcionalidade: capacidade de executar as funcionalidade requeridas
    Usabilidade: Capacidade de o software ser compreendido, aprendido, usado e apreciado pelo usuário, quando usado nas condições especificadas
    Confiabilidade:   Capacidade de o software manter seu nível de desempenho quando usado nas condições especificadas
    Eficiência:   Capacidade de o software operar no nível de desempenho requerido em relação à quantidade de recursos empregados, quando usado nas condições especificadas
    Manutenibilidade: Capacidade de realizar manutenções no software
    Portabilidade: capacidade de ser utilizado em diferentes ambientes.
  • Questão anulada - Conforme alteração Gabarito -
    http://www.questoesdeconcursos.com.br/concurso/justificativa/622/mec-2009-tecnologia-justificativa.pdf

ID
173338
Banca
FGV
Órgão
MEC
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Ferramentas de software, frequentemente utilizadas por Analistas de Qualidade e Testes, estão relacionadas a seguir, à exceção de uma. Assinale-a.

Alternativas
Comentários
  • Filezilla é de FTP, que opera na porta 21 e 20 utilizando TCP/IP.  Porta 21 para comandos, porta 20 para dados.

     

  • Típica questãozinha que não avalia nad ...

ID
177922
Banca
FCC
Órgão
TRT - 9ª REGIÃO (PR)
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

O teste de sistema que força o software a falhar de diversos modos e verifica o retorno do processamento dentro de um tempo pré-estabelecido é um tipo de teste de

Alternativas
Comentários
  •  O teste de recuperação é usado para verificar a robustez do software em retornar a um estado estável de execução após estar em um estado de falha.

  • Conceito retirado do livro Engenharia de Software, de Roger S. Pressman, 6ª Ed. (página 306)

    "O teste de recuperação é um teste de sistema que força o software a falhar de diversos modos e verifica se a recuperação é adequadamente realizada... Se a recuperação requer intervenção humana, o tempo médio para reparo é avaliado para determinar se está dentro de limites aceitáveis."

    Logo, resposta correta, letra c.

    Espero ter colaborado.

  • Uma dúvida que tive nessa questão é a diferença do teste Desempenho X Estresse.

    1) Teste de desempenho: busca extrair informações sobre o desempenho do sistema em cenários normais de uso.

    2) Teste de stress: busca extrair informações sobre quando o sistema não suporta a carga aplicada.

  • O Teste de recuperação é um tipo de teste de sistema que força o sw a falhar de diversas formas e verifica se a recuperação é executada corretamente. Aqui é considerado o tempo médio reparo(MTTR).

     

    Fonte: Pressman

  • Teste de Recuperação: é um teste do sistema que força o software a falhar de várias formas e verifica se a recuperação é executada corretamente.

    Alternativa: C


ID
188731
Banca
FCC
Órgão
TRT - 9ª REGIÃO (PR)
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

A técnica de teste de software, também chamada de comportamental, é a técnica de

Alternativas
Comentários
  • Gabarito: A

     Caixa presta, também chamado de teste comportamental, focaliza os requisitos funcionais do software. Isto é, o teste caixa-preta permite ao engenheiro de software derivar conjuntos de condições de entrada que vão exercitar plenamente todos os requisitos funcionais de um programa

  • Falando de outra forma:

    Testes de caixa preta (Comportamenteal) testa se as funções do sistema funcionam ou não. Ex: Se tem um botao que ao ser clicado deve abrir uma tela com determinadas características, é checado se isso está ok. Se tem um campo que só deve permitir a entrada de número, texto deve ser impedido. É isso. Acho que é um dos testes mais fáceis de fazer, se comparado aos demais.
  • Teste de caixa branca

    O analista  tem acesso ao código fonte, conhece a estrutura interna do produto sendo analisado e possibilita que sejam escolhidas partes específicas de um componente para serem avaliadas. Esse tipo de teste, também conhecido como teste estrutural, é projetado em função da estrutura do componente e permite uma averiguação mais precisa do comportamento dessa estrutura. Perceba que o acesso ao código facilita o isolamento de uma função ou ação, o que ajuda na análise comportamental das mesmas.

    Teste de caixa preta

    O analista não tem acesso ao código fonte e desconhece a estrutura interna do sistema. É também conhecido como teste funcional, pois é baseado nos requisitos funcionais do software. O foco, nesse caso, é nos requisitos da aplicação, ou seja, nas ações que ela deve desempenhar.

    Para mostrar quais problemas que esse tipo de teste rastreia, podemos citar alguns exemplos:

    Data de nascimento preenchida com data futura;

    Campos de preenchimento obrigatório que não são validados;

    Utilizar números negativos em campos tipo valor a pagar;

    Botões que não executam as ações devidas;

    Enfim, todo tipo de falha funcional, ou seja, falhas que contrariam os requisitos da aplicação.

    Há que se destacar, contudo, que existe um elemento comum aos dois tipos de teste. Tanto no teste de caixa branca quanto no teste de caixa preta, o analista não sabe qual será o comportamento da aplicação ou do alvo de teste em uma determinada situação. A imprevisibilidade de resultados é comum aos dois casos.

    Resumindo....:

    Teste de caixa-preta: Testa todas as entradas e saídas desejadas. Não se está preocupado com o código, cada saída indesejada é visto como um erro.

    Teste caixa-branca: O objetivo é testar o código. Às vezes, existem partes do código que nunca foram testadas.

  • Gabarito A

    Essas técnicas de Teste se dividem entre Funcional e Estrutural, sendo que o Teste Funcional, ou Teste de Caixa Preta (Black Box), é aquele que tem como alvo verificar se a implementação está de acordo com o que foi especificado. Já o Teste Estrutural, também chamado de Teste de Caixa Branca (White Box), busca garantir que o software desenvolvido esteja bem estruturado internamente, portanto, funcionando corretamente.

     

    "Retroceder Nunca Render-se Jamais !"
    Força e Fé !
    Fortuna Audaces Sequitur !
     


ID
190750
Banca
CESGRANRIO
Órgão
ELETROBRAS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

O coordenador da equipe de testes de uma fábrica de testes deseja implantar uma ferramenta de gestão de defeitos. Para tanto, ele precisa escolher entre três opções, que são:

Alternativas
Comentários
  • Bugzilla:
    O Bugzilla é uma aplicação para gestão de erros. Esta aplicação permite que indivíduos ou grupos de programadores acompanharem os relatórios de erros ou pedidos de melhoramentos. Escrito em Perl.

    é uma ferramenta baseada em Web e e-mail que dá suporte ao desenvolvimento do projeto Mozilla, rastreando bugs e servindo também como plataforma para pedidos de recursos. Como projeto de Software Livre, é mantido por voluntários, sendo utilizado por diversos outros projetos de código aberto.

    http://www.mozilla-europe.org/pt/products/bugzilla/

    Jira:
    JIRA é uma aplicação J2EE de acompanhamento e gestão dos problemas desenvolvida para esse processo mais fácil para o sua equipe.


    JIRA é um programa de gestão de projetos e acompanhamento de tarefas e erros. Fácil de usar, oferece grande flexibilidade, de forma que você possa fazer o acompanhamento de tudo desde sua criação até finalização, assinalando o assunto e seu responsável com a possibilidade de se fazer comentários e capturas. O espectador pode ser informado por e-mail de todas as mudanças efetuadas.

    http://www.mondo.com.br/jira/


    Trac é uma simples ferramenta, open source e de interface web para controle de mudanças em projetos de desenvolvimento de software. O objetivo do software é ajudar o desenvolvedor a rastrear essas mudanças, entender o porque de cada uma e qual o seu impacto no projeto como um todo.

    Recursos do Trac

    * Controle de mudanças;
    * Wiki para documentação colaborativa e referência cruzada entre os elementos do Trac;
    * Integração com o Subversion (Trac também funciona como um browser do repositório do Subversion);
    * Acompanhamento da evolução do projeto.

    [editar] Benefícios obtidos com o uso do Trac

    * Melhoria na qualidade do produto e do processo de desenvolvimento;
    * Registro, rastreamento e controle das mudanças sofridas pelo projeto durante o seu ciclo de vida;
    * Integração entre o controle de versão e o controle de mudança;
    * Acompanhamento básico da evolução do projeto;
    * Melhor documentação do projeto através de participação da equipe de desenvolvimento.

    fonte: http://pt.wikipedia.org/wiki/Trac

  • Corretos:

    JIRA 
    -
    software comercial usado para gestão de bugs (issue tracker e bug tracker). É open-source, mas licenciado. 

    Bugzilla -  ferramenta baseada em Web e e-mail que dá suporte ao desenvolvimento do projeto Mozilla, rastreando defeitos e servindo também como plataforma para pedidos de recursos (gestão de mudanças). Open-source e gratuita.

    Trac - ferramenta open source, gratuita e de interface web para controle de mudanças em projetos de desenvolvimento de software.

    Errados:

    JUnit
    - Framework para criação de testes unitários automatizados em Java. Não é ferramenta de gestão de mudanças/defeitos.

    TestComplete - Ferramenta de criação de testes funcionais automatizados que suporta diversas tecnologias:  .NET, Java, Visual Basic, Borland Delphi, WEB, PowerBuilder, FoxPro, entre outros.
  • Vale a pena dar uma olhada:
    http://www.devmedia.com.br/articles/viewcomp.asp?comp=8036


ID
195274
Banca
CESPE / CEBRASPE
Órgão
TCU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens seguintes, a respeito de engenharia de requisitos.

O checklist de validação é uma forma útil de averiguar se determinado requisito pode ser testado e, em caso afirmativo, se os testes podem ser especificados.

Alternativas
Comentários
  •  É frequentemente útil examinar cada requisito em face de um conjunto de questões do tipo checklist. Eis aqui um pequeno subconjunto de questões que poderiam ser formuladas:
    (…)
    O requisito pode ser testado? Em caso positivo, podemos especificar os testes (algumas vezes chamados critérios de validação) para exercitar o requisito? (…)

     

    comentado por Alessandra Lima
    http://waltercunha.com/blog/index.php/2010/09/22/questoes-de-engenharia-de-requisitos-da-prova-tcu-2010/

  • Fonte: Engenharia de Software - Roger s. Pressman (Sexta Edição)
    Página: 120

    7.2.6 - Validação
    Checklist de Validação dos Requisitos
    É frequentemente útil examinar cada requisito em face de um conjunto de questões do tipo checklist. Eis aqui um pequeno subconjunto de questões que poderiam ser formuladas: (...) O requisito pode ser testado? Em caso positivo, podemos especificar os testes (algumas vezes chamados critérios de validação) para exercitar o requisito? (…)
  • Para sommerville:

    Os artefatos produzidos como consequência da engenharia de requisitos são avaliados quanto à qualidade durante a etapa de validação

    A validação examina a especificação (Em alguns casos, a especificação é um conjunti de cenários de usuários e pouco mais do que isso. Em outros, a especificação pode ser um documento contentando cenários, modelos e descrições por escrito) para garantir que todos os requisitos tenham sido declarados de forma não ambígua, que as inconsistências, omissões e erros tenham sido detectados e corrigidos e que os artefatos estejam de acordo com os padrões estabelecidos para o processo, projeto e produto

    O principal mecanismo de validação de requisitos é a revisão técnica. A equipe de revisão (engenheiros, clientes, usuários e outros interessados) examinam a especificação em busca de erros no conteúdo ou na interpretação, áreas em que talvez sejam necessários esclarecimentos de informações faltantes, de inconsistências, requisitos conflitantes ou requisitos irreais (inatingíveis)

    Para isso, pode ser usada um check list de validação de requisitos: examina cada requisito em relação a um conjunto de perguntas contidas em uma lista de controle


  • Isso não é Verificação não?



ID
197506
Banca
CESPE / CEBRASPE
Órgão
DETRAN-DF
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca do desenvolvimento de aplicações e da arquitetura OLAP,
julgue os itens a seguir.

O processo de validação tem por objetivo estabelecer com os clientes confiança quanto ao funcionamento adequado de um software. Enquanto inspeções de software ou revisões por pares são consideradas validação estática, o teste consiste em uma técnica dinâmica de validação de software. Os termos estático ou dinâmico são relativos à necessidade ou não do software ser executado.

Alternativas
Comentários
  • Ou seja:
    Validação - de acordo ao uso (ao cliente) (dinamico_
    Verificação - de acordo com os requisitos (estático)
  • Não concordei com o gabarito desta questão.
    O trecho: Enquanto inspeções de software ou revisões por pares são consideradas validação estática
     
    Pelo que pude perceber há uma imprecisão quanto ao conceito de validação.  O problema é que a frase inicial ao invés de direcionar qual o contexto usado para o termo validação insere ainda mais confusão.
     
    O processo de validação tem por objetivo estabelecer com os clientes confiança quanto ao funcionamento adequado de um software
     
    A meu ver na questão não foram utilizados os conceitos de Verificação e Validação, já que nesses as inspeções e as revisões por pares estariam no domínio da Verificação.

    PS: O comentário anterior não define corretamente os conceitos, pois não há essa classificação de Verificação ser estática e Validação ser dinâmica. Pode haver verificação estática (inspeção) ou dinâmica (teste). O mesmo vale para a Validação.
  • De acordo com Sommerville (9 ed., pag. 275), técnicas de analise estática sao técnicas de VERIFICAÇÃO de sistema. Segundo ainda o autor, "talvez a técnica de analise estatica mais usada seja a revisao e inspeção em pares...". Ora, a questão diz em "validação estática", o que está em desacordo com Sommerville. Assim, eu assinalaria Errado.
  • Putz...essas questões são para desanimar....

    por mais que você saiba a matéria, o Cesp INVENTA conceitos próprios , e pior, não volta atrás mesmo com a literatura mundial monstrando que ele esta errado!
  • Houve uma confusão do examinador (estagiário) quanto aos conceitos de Validação e Verificação.

    Ao meu ver... questão ERRADA.

  • Considero a questão como ERRADA pelo seguinte trecho destacado:

     

    O processo de validação tem por objetivo estabelecer com os clientes confiança quanto ao funcionamento adequado de um software. Enquanto inspeções de software ou revisões por pares são consideradas validação estática, o teste consiste em uma técnica dinâmica de validação de software. Os termos estático ou dinâmico são relativos à necessidade ou não do software ser executado.

     

    O mais correto seria verificação estática, a meu ver.

  • vERificação >> Especificação de Requisitos

    validação >> de acordo com o cliente

  • Gabarito da questão: Certo.

  • Análise estática de softwares, também conhecida como whitebox, trabalha diretamente com o código de uma ferramenta. Nesse caso, os componentes de uma ferramenta são verificados sem que o produto seja executado. Seja por meio de uma ferramenta automatizada ou dos testes manuais, o principal objetivo dessa técnica é identificar erros de programação, tais como: Práticas ruins; Erros de sintaxe; Falhas de segurança.

    Teste dinâmico pode ser empregado de forma complementar a análise estática. Esse tipo de abordagem vê o software como uma “caixa preta” (daí o nome popular “blackbox”) e trabalha, principalmente, com o desempenho e com as informações que são inseridas nas rotinas de entrada e saída de dados. Além disso, são verificados itens como: O tempo de resposta; A performance da aplicação; A capacidade do software se adaptar a diferentes ambientes; O comportamento funcional.


ID
201325
Banca
CESPE / CEBRASPE
Órgão
Banco da Amazônia
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Teste rápido é um mecanismo para identificar requisitos de software.

Alternativas
Comentários
  • O objetivo de teste é ENCONTRAR ERRO.

  • Em outros carnavais, se aparecer assim:

    Prototipação é uma forma de identificar requisitos de um software.

    ( x ) certo

  • Complementando o colega leoh:
    Teste rápido ou Teste Negativo tem a finalidade de encontrar erro.

  • Na verdade colegas, a validação dinâmica ou teste, tem a intenção de descobrir defeitos no programa ou mostrar que o mesmo atende seus requisitos.

    erro = engano cometido por ser humano
    defeito = resultado desse erro
    falha = resultante de um defeito

    abrasss

    fontes: sommerville e blog qualidadebr
  • Só complementando o comentário dos colegas.

    Na página da Microsoft associaram o termo "teste rápido" ao "teste de fumaça". Segue o trecho:

    "O termo teste rápido (smoke test) originou-se na indústria de hardware. O termo é derivado de nesta sessão prática: Depois que um pedaço de hardware ou um componente de hardware foi alterado ou reparado, o equipamento era simplesmente ligado. Se não houvesse nenhuma fumaça (smoke), o componente passou no teste."

    "http://msdn.microsoft.com/pt-br/library/ms182613%28v=vs.90%29.aspx"

    Procurei o conceito de teste rápido no livro do Pressman e não achei nada a respeito. Se alguém encontrar algo sobre esse tipo de teste em livros consagrados, favor informar.


  • Complementando o comentário da Carla Rodrigues:


    Teste de fumaça (smoke test), segundo o professor Fernando Pedrosa: 

    É um termo usado em várias áreas e refere-se ao primeiro teste realizado depois de integrar os componentes. Em Software, é aplicado após cada montagem (build) do produto para verificar sua funcionalidade básica. O intuito deve ser o de encontrar erros que têm a maior probabilidade de atrasar o projeto (show stopper errors).

    Ou seja, é um teste para checar se você pode continuar testando. É focado nas funcionalidades básicas (não é exaustivo e nem profundo - teste em largura) e vem antes do teste de regressão.


    Bons estudos!


ID
201352
Banca
CESPE / CEBRASPE
Órgão
Banco da Amazônia
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

A validação é o processo para determinar se os produtos de software de uma atividade atendem completamente aos requisitos ou condições impostas a eles nas atividades anteriores, enquanto a verificação determina se os requisitos e o produto final, sistema ou produto de software construído atendem ao uso específico pretendido.

Alternativas
Comentários
  • Questão simples, os conceitos de validação e verificação estão invertidos.

  • A Verificação é o processo para determinar se os produtos de software de uma atividade atendem completamente aos requisitos ou condições impostas a eles nas atividades anteriores ou seja se "os produtos atendem os Requisitos".
    enquanto a Validação determina se os requisitos e o produto final, sistema ou produto de software  construído atendem ao (Cliente) uso específico pretendido .
  • A validação Verificação é o processo para determinar se os produtos de software de uma atividade atendem completamente aos requisitos ou condições impostas a eles nas atividades anteriores, enquanto a verificação Validação determina se os requisitos e o produto final, sistema ou produto de software construído atendem ao uso específico pretendido.
  • Verificação = Processo 
    Validação = Produto Final ( Software )
  • A verificação é o processo para determinar se os produtos de software de uma atividade atendem completamente aos requisitos ou condições impostas a eles nas atividades anteriores, enquanto a validação determina se os requisitos e o produto final, sistema ou produto de software construído atendem ao uso específico pretendido.

    como o colega colocou, verifica-se processos, o usuario valida o sw.

    1° se verifica, depois se valida


ID
201502
Banca
FCC
Órgão
BAHIAGÁS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Na direção dos tipos de teste focados pela engenharia de software, os testes de integração cuidam dos tópicos associados com os problemas de verificação

Alternativas
Comentários
  •  Tem uma figura no pressman que explica a evolução dos testes:

    1 - Testes de unidade estão associados com o código fonte
    2 - Testes de integração estão associados com problemas de projeto
    3 - Testes de validação estão associados com requisitos
    4 - Testes de sistema estão associados com a engenharia de sistemas

    [1] Pressman, 6ª edição, Engenharia de Software, pag. 291

  • Complementando comentário anterior...
    Pressman, 4ª edição, Engenharia de Software, pag. 840
  • Qual a diferença ente a engenharia do sistema e o projeto do sistema??

  • a) da engenharia de sistemas. -> Teste de Sistema b) do projeto do software. -> Teste de Integração c) dos códigos de programa. -> Teste Unitáriod) dos requisitos funcionais. -> Teste de Aceitaçãoe) dos requisitos não funcionais. -> Teste de Aceitação

ID
205348
Banca
FEPESE
Órgão
SEFAZ-SC
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Analise a definição abaixo.

Teste de software que procura descobrir erros por meio da reaplicação parcial dos testes a um programa modificado.

Assinale a alternativa que cita corretamente o conceito ao qual se refere a definição.

Alternativas
Comentários
  • Teste de Regressão

    Realizado na fase de integração

    Reexecução de testes já conduzidos para garantir que as modificações não propagem efeitos colaterais.

    USa-se, por exemplo, JUnit para automatizar.

  • O teste de regressão é uma técnica do teste de software que consiste na aplicação de testes à versão
    mais recente do software, para garantir que não surgiram novos defeitos em componentes já testados.
    Se, ao juntar o novo componente ou as suas alterações com os componentes restantes do sistema surgirem
    novos defeitos em componentes inalterados, então considera-se que o sistema regrediu.

    Muitas vezes são usadas ferramentas específicas para o teste de regressão, chamadas de ferramentas de automação.
    Elas conseguem um resultado mais exato do teste executando exatamente os passos seguidos para o teste das primeiras
    versões já que elas permitem a gravação do teste.

    Fonete: http://pt.wikipedia.org/wiki/Teste_de_regress%C3%A3o
  • https://memorexti.wordpress.com/2016/02/25/testes-de-software-23/

  • Prezados,

    O teste de regressão é uma técnica do teste de software que consiste na aplicação de versões mais recente do software, para garantir que não surgiram novos defeitos em componentes já analisados. Se, ao juntar o novo componente ou as suas alterações com os componentes restantes do sistema surgirem novos defeitos em componentes inalterados, então considera-se que o sistema regrediu.   

    Portanto a alternativa correta é a letra C


ID
215740
Banca
CESPE / CEBRASPE
Órgão
MPU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

No processo de teste de software, uma das metas consiste em
demonstrar ao desenvolvedor e ao cliente que o software atende aos
requisitos, e outra, em descobrir falhas ou defeitos no software que
apresenta comportamento incorreto. Quanto aos processos de teste
de software, julgue o próximo item.

O teste de integração geralmente é um processo de teste de caixa-preta no qual os testes são derivados da especificação do sistema, cujo comportamento pode ser determinado por meio do estudo de suas entradas e saídas.

Alternativas
Comentários
  •  Aparentemente, o CESPE apenas trocou testes de releases por teste de integração na definição dada por Sommerville (item 23.1.2):

    O teste de releases geralmente é um processo de teste caixa-prata no qual os testes são derivados da especificação do sistema. O sistema é tratado como uma caixa-preta, cujo comportamento pode ser somente determinado por meio do estudo de suas entradas e as saídas relacionadas. Outro nome para isso é teste funcional, pois o testador concentra-se na funcionalidade, e não na implementação do software.

  • Perfeito o comentário abaixo, só complementando:

     

    13.3.2 Teste de Integração

    • É uma técnica sistemática para construir a arquitetura do software enquanto, ao mesmo tempo, conduz testes para descobrir erros associados às interfaces.
    • O objetivo é, a partir de componentes testados no nível de unidade, construir uma estrutura de programa determinada pelo projeto.
  • Teste de integração: é a fase de teste em que os módulos são combinados e testados em grupos. Ele sucede o teste de unidade e antecedo o teste de sistema completo - que é testado em ambiente de produção.
    Na fase de teste de integração o objetivo é encontrar falhas provenientes da integração interna  dos componentes do sistema. É verificado os requisitos funcionais, de desempenho e de confiabilidade na modelagem do sistema.

ID
215743
Banca
CESPE / CEBRASPE
Órgão
MPU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

No processo de teste de software, uma das metas consiste em
demonstrar ao desenvolvedor e ao cliente que o software atende aos
requisitos, e outra, em descobrir falhas ou defeitos no software que
apresenta comportamento incorreto. Quanto aos processos de teste
de software, julgue o próximo item.

No desenvolvimento orientado a objetos embasados em componentes, os objetos e os componentes são definidos por suas interfaces e podem ser reusados em combinação com outros componentes em diferentes sistemas. Nesse caso, o teste de interfaces é particularmente útil, porque erros de interface em componentes compostos (formados pela combinação de componentes) não podem ser detectados por meio de testes de objetos ou componentes individuais.

Alternativas
Comentários
  • Testes de interface

     
    Ocorrem quando módulos ou subsistemas são 
    integrados para criar sistemas maiores. 

     
    Objetivo é detectar erros devido a erros ou 
    suposições inválidas sobre interfaces. 


    Particularmente importante para o desenvolvimento orientado a objeto, uma vez 

    que os objetos são definidos por suas interfaces 


    Fonte: http://www.dcce.ibilce.unesp.br/~ines/cursos/eng_soft/aula13.PDF
  • Acho que a questão ficaria mais correta se fosse assim: "...Nesse caso, o teste de interfaces é particularmente útil, porque erros de interface em componentes compostos (formados pela combinação de componentes) podem não  ser detectados por meio de testes de objetos ou componentes individuais.
    Abraços, vamo que vamo.
  • cespe cobra umas definições de testes no mínimo estranhas

ID
218170
Banca
CESPE / CEBRASPE
Órgão
TRE-BA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Quanto ao teste de software, julgue os itens que se seguem.

Segundo o IEEE, defeito é um ato inconsistente cometido por um indivíduo ao tentar entender determinada informação, resolver um problema ou utilizar um método ou uma ferramenta; erro é o comportamento operacional do software diferente do esperado pelo usuário, e que pode ter sido causado por diversas falhas; e falha é uma manifestação concreta de um defeito em um artefato de software, ou seja, é qualquer estado intermediário incorreto ou resultado inesperado na execução de um programa.

Alternativas
Comentários
  •  Pegadinha cruel da banca.

     

    · Defeito é um ato inconsistente cometido por um indivíduo ao tentar entender uma determinada informação, resolver um problema ou utilizar um método ou uma ferramenta. Por exemplo, uma instrução ou comando incorreto.


    · Erro é uma manifestação concreta de um defeito num artefato de software. Diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado intermediário incorreto ou resultado inesperado na execução de um programa constitui um erro.


    · Falha é o comportamento operacional do software diferente do esperado pelo usuário. Uma falha pode ter sido causada por diversos erros e alguns erros podem nunca causar uma falha.

  • Deve-se tomar cuidado com as definições.
    Neste caso, a questão foi explicita ao pedir os conceitos da IEEE, especificamente IEEE 610 define esses termos como abaixo.

    Defeito (fault)
    1. ato inconsistente cometido por um indivíduo ao tentar entender uma determinada informação, resolver um problema ou utilizar um método ou uma ferramenta
    2. pode ocasionar a manifestação de erros em um produto
    3. instrução ou comando incorreto (hardware/software fault)
    4. causa raiz é sempre o defeito (a falta)

    Erro (error)
    1. manifestação concreta de um defeito num artefato de software
    2. qualquer estado intermediário incorreto ou resultado inesperado na execução de um programa constitui um erro
    3. diferença entre o valor obtido e o valor esperado
    4. construção de um software de forma diferente ao que foi especificado (universo de informação)

    Falha (failure)
    1. comportamento operacional do software diferente do esperado pelo usuário
    2. diferença indesejável entre o observado e o esperado, é um evento
    3. uma falha pode ter sido causada por diversos erros e alguns erros podem nunca causar uma falha
    4. afetam diretamente o usuário final da aplicação (universo do usuário)
    5. pode inviabilizar a utilização de um software
    6. estado intermediário de instabilidade podendo resultar em uma falha


    No entanto, Roger S. Pressman insere definições distintas a da norma IEEE 610.
    Erro
    1. problema de qualidade encontrado antes que o software seja entregue
    2. depura-se para descobrir erros

    Defeito
    1. problema de qualidade encontrado depois que o software foi entregue (Pressman)
    2. testa-se para descobrir defeitos

  • Usando as informações dos dois amigos abaixo:

    Segundo o IEEE, defeito é um ato inconsistente cometido por um indivíduo ao tentar entender determinada informação, resolver um problema ou utilizar um método ou uma ferramenta; FALHA é o comportamento operacional do software diferente do esperado pelo usuário, e que pode ter sido causado por diversOs ERROS; e ERRO é uma manifestação concreta de um defeito em um artefato de software, ou seja, é qualquer estado intermediário incorreto ou resultado inesperado na execução de um programa.

  • Vamos lá galera:

    Erro: Engano cometido por seres humanos

    Defeito: Resultado do erro

    Falha: Resultado do defeito

    exemplo:  erro de lógica(erro), gerando loop infinito(defeito), fazendo o sistema travar (falha)

    http://qualidadebr.wordpress.com/2008/07/02/defeito-erro-e-falha-e-tudo-igual/

  • Geralmente utilizo uma estratégia para matar essas questões de: Defeito, Erro e Falha.

    A primeira letra que vem dos três o D a segunda é o E e a terceira é o F, com isso basta lembrar da seguinte ordem:

    Os DEFEITOS podem provocar ERROS e os ERROS podem provocar FALHAS.

    Onde matei a questão utilizando essa estratégia: "erro é o comportamento operacional do software diferente do esperado pelo usuário, e que pode ter sido causado por diversas falhas;" - ERRADO


  • Diego você trocou as bolas entre Erro e Defeito! Acontece nas melhores famílias. :-)

  • Só destacando que o 1º conceito  (Defeito / Falta) está correto.

    O erro da questão está na troca entre os dois últimos (Erro e Falha).


ID
226312
Banca
CESGRANRIO
Órgão
EPE
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Um novo sistema de informação interno de uma empresa está sendo testado por um grupo restrito de usuários, fora do ambiente dos desenvolvedores. Isso caracteriza o teste

Alternativas
Comentários
  • Teste de Unidade é uma fase (não é uma técnica) dos testes onde componentes individuais como classes e funções são testados. É um teste estrutural, cujo o objetivo é percorrer os caminhos lógicos dentro do código em busca de erros.

    Teste de Usabilidade é uma técnica ( não é uma fase), não-funcional.

    Teste Alfa é uma fase de teste onde o software é testado no ambiente dos desenvolvedores, sob o olhar deles.

    Teste Beta é uma fase de teste onde o software é testado por um grupo de usuários fora do ambiente de desenvolvimento.

    Teste de Stress, também conhecido como teste de carga. É usado para verificar o limite de um software, em relação ao processamento de dados. É uma técnica não-funcional.

  •  d)beta.

    O teste beta implica coletar usuários para testar um app ou sistema para obter reports & feedback para melhor adaptablidade ao publico padrao


ID
230938
Banca
FUNCAB
Órgão
PRODAM-AM
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Teste baseado em riscos é um tipo de teste de software que:

Alternativas
Comentários
  • Processo que define os testes baseados em riscos:
    1. Faça uma lista de riscos por prioridade.
    2. Realize testes que exploram o risco.
    3. A medida que os riscos evaporam e riscos novos aparecem, ajuste seu esforço de
    teste para focar na tarefa atual.

    Apesar de simples, esta definição contém a essência da técnica, ou seja, o foco do teste baseado em risco é na análise do software e na criação de um plano teste baseado nas áreas que possuam a maior probabilidade de apresentarem problemas que teriam o maior impacto sobre o mesmo .


ID
234334
Banca
NC-UFPR
Órgão
UFPR
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre os objetivos de teste de software, considere as seguintes afirmativas:

1. A atividade de teste é o processo de executar um programa com a intenção de descobrir um erro.

2. A atividade de teste pode comprovar a ausência de erros.

3. Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto.

4. Um teste bem-sucedido é aquele que revela um erro não descoberto.

Assinale a alternativa correta.

Alternativas
Comentários
  • 1. A atividade de teste é o processo de executar um programa com a intenção de descobrir um erro. 

    Discordo a definição. Será que a execução é sempre necessária para efetuar testes?
  • Discordo também da alternativa 4 ser verdadeira. Um treste bem-sucedido não necessariamente é aquele revela um erro. E se o programa estiver ok? O teste não pode ser bem-sucedido?
  • Complementando a ideia:
    A atividade de teste pode comprovar a ausência de erros: Como podemos perceber, não existe sistema perfeito, todos sistema são passiveis de erros. e são os testes que irão revelar os erros.
  • Sobre a afirmativa 2: É impossível um teste comprovar que um software está 100% livre de erros. Assim como não há software livre de erros.
  • Mesmo acertando a questão discordo do gabarito.
    A alternativa I afirma que a atividade de teste é o processo de executar um programa....
    Discordo no seguinte ponto, há um tipo de teste chamado: Teste Humano ou Estático, que não leva em consideração a sua execução, mas somente a forma conceitual do programa. Utilizado normalmente na fase de Elicitação de Requisitos, Projeto Preliminar...
    Ao meu ver, quando se é feito este tipo de teste estamos utilizando o que se conceitua atividade de teste.

    []'s e bons estudos.
  • 2- A atividade de teste não prova a ausência de erros!

  • Peço desculpa aos engenheiros de software que comentaram abaixo, com discordância...

    99% das questões as bancas se apoiam bibliografias consagradas e ponto final. Entendo o ponto de vista de 'discordar' de tal gabarito, mas como os professores do falecido ITnerante falavam: 'muitas vezes o examinador copia e cola, sem ao menos saber do conteúdo' é o caso desta questão.

    A questão foi extraída do livro: Engenharia de Software - Pressman

    1. A atividade de teste é o processo de executar um programa com a intenção de descobrir um erro.

    O que diz no livro: Teste é um processo de execução de um programa com a finalidade de encontrar um erro;

    Portanto: CORRETA

    .

    2. A atividade de teste pode comprovar a ausência de erros.

    O que diz no livro: '... os dados coletados à media que o teste é conduzido fornecem uma boa indicação da confiabilidade do software e alguma indicação da qualidade de todo o software, mas o teste não pode mostrar a ausência de erros e defeitos.'

    Portanto: INCORRETA

    .

    3. Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto.

    O que diz no livro: Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto. ( Copia e cola)

    Portanto: CORRETA

    .

    4. Um teste bem-sucedido é aquele que revela um erro não descoberto.

    O que diz no livro: Um teste bem-sucedido é aquele que revela um erro não descoberto. ( Copia e Cola)

    Portanto: CORRETA

    GABARITO, AMPARADO BIBLIOGRAFICAMENTE, ALTERNATIVA D


ID
235393
Banca
CETAP
Órgão
AL-RR
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Durante o processo de desenvolvimento de software, é necessário garantir que o software em desenvolvimento esteja satisfazendo os requisitos. Isto é realizado através de processos de teste do software. Selecione das seguintes alternativas, a CORRETA.

Alternativas
Comentários
  • a) Nada a ver.
    b) Testes de caixa-preta: Técnica de teste em que o componente de software a ser testado é abordado como se fosse uma caixa-preta, ou seja, não se considera o comportamento interno do mesmo. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido. Logo, nenhum código é analisado
    c) Testes funcionais também são chamados de testes de caixa-preta.
    d) Testes não funcionais
    verificam a operação correta do sistema em relação a casos inválidos ou inesperados de entrada. É uma forma de testar a tolerância e a robustez do software em lidar com o inesperado.

ID
239734
Banca
CESPE / CEBRASPE
Órgão
ABIN
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir, relativos a métodos de desenvolvimento de
software.

Para a verificação de resultados de um protótipo de sistema, podem-se utilizar testes back-to-back, nos quais os mesmos casos de teste são submetidos ao protótipo e ao sistema em teste a fim de se produzir um relatório de diferenças.

Alternativas
Comentários
  • Usa-se teste de comparação quando a confiabilidade do software é absolutamente crítica. Alguns pesquisadores tem sugerido que versões independentes de software sejam desenvolvidas para aplicações críticas , mesmo quando uma única versão for usada no sistema copmputadorizado entregue.Essas versões independentes formam a base de uma técnica de teste de caixa preta denominada teste de comparação ou teste back-to-back.

    O método de comparação não é infalível. Se a especificação a partir da qual todas as versões foram desenvolvidas estiver errada, provavelmente todas as versões refletirão o erro. Além disso, se cada uma das versões independentes produzir resultados idênticos, mas incorretos, os testes de condições deixarão de detectar o erro.

  • "Quando um protótipo de sistema está disponível, você pode reduzir o esforço envolvido na verificação de resultados pela realização de testes back-to-back. Os mesmos casos de teste são submetidos ao protótipo e ao sistema em teste"

    Fonte: Engenharia de Software Sommervile - página 271
  • seriam os testes de regressão?

  • Prezados,

    Segundo Emerson Moreira Rios, em seu livro Teste de Software, página 19 , temos :

    Testes back-to-back : O mesmo teste é executado em versões diferentes do software e os resultados são comparados.

    Portanto a questão está correta.

  • Para quem não entende os comentários sem o gabarito e não tem acesso a resposta.

    Gaba: CERTO

  • testes back-to-back reduz esforço envolvido na verificação de resultados


ID
239737
Banca
CESPE / CEBRASPE
Órgão
ABIN
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação à engenharia de requisitos, julgue os itens a seguir.

Considerando-se o programa final como caixa preta, a validação dinâmica, ou teste, pode ser utilizada para identificar a ocorrência de defeitos no programa ou para confirmar se ele atende aos requisitos estabelecidos.

Alternativas
Comentários
  • A validação dinâmica consiste em validar o software por meio de sua execução. A validação estática analisa o código fonte.

    O programa final está fechado e compilado. Não aplica-se mais testes estáticos (código fonte) nestas condições. Portanto, executamos testes dinâmicos (rodamos o programa) para validá-lo (atende aos requesitos estabelecidos?) e identicar ocorrência de defeitos.

  • Inspeções de software - preocupa-se com a análise estática das representações do sistema para descobrir problemas (Verificação estática).
    Teste de software - preocupa-se com a execução e observação do comportamento do produto (Verificação dinâmica).
    Pelo que percebi, a palavra validação foi usada incorretamente na questão. Deveria ser Verificação.
    Fonte: http://www.dcce.ibilce.unesp.br/~ines/cursos/eng_soft/aula12.PDF
  • Considerando-se o programa final como caixa preta, a validação dinâmica, ou teste, pode ser utilizada para identificar a ocorrência de defeitos no programa ou para confirmar se ele atende aos requisitos estabelecidos.

    Errei a questão por achar que essa última parte era conceitos de Verificação...

    Bom, Fica a dúvida.
  • Essa questão é um pouco complicada, pois de acorco com a IEEE 729 durante o teste são observadas as falhas e não os defeitos.
    Defeito (Fault): Instrução ou definição incorreta. Por exemplo: 
    int v[10];
    for (int i=0; i<=10;i++)
        v[i]=i; 
    Falha (Failure): Resultados incorretos (manifestação do defeito, no exemplo anterior, a utilização de v[10]);
    Mas acho que nessa questão é aceitável que o termo "ocorrência de defeitos" seja sinônimo de "falhas".
  • Também errei, pelo mesmo motivo dos colegas. O problema é que esse trecho tá lá no danado do Sommerville, segue:
    Verificação e validação é o processo que demonstra que um programa atende a sua especificação (verificação) e atente às necessidades reais dos seus stakeholders (validação). As técnicas de verificação estáticas enfocam a análise manual ou automática do código fonte do programa. A validação dinâmica ou teste tem a intenção de descobrir defeitos no programa ou demonstrar que o programa atente a seus requisitos.
    (Fonte: Engenharia de Software, 8ed, Sommerville, pag 522)
    Gabarito "Certo".
  • Nós aprendemos, em TODAS as literaturas de engenharia de software, que verificação e validação são coisas (e termos) completamente diferentes. Não para a CESPE! Ela segue suas próprias regras. Terrível para a pessoa que estuda e que, por conseguinte, errará a questão. Quem não estuda, no chute, tem mais chance de acertar.

     

    Só um desabafo...

  • Prezados,

    Considerando-se o programa final como uma caixa preta ( ou seja , não tendo acesso ao código fonte ), a validação dinâmica pode ser utilizada para identificar a ocorrência de defeitos no programa e também para verificar se ele atende aos requisitos.
    Na validação dinâmica temos a validação por meio da execução do software , enquanto na validação estática temos a análise do código fonte e outras representações do software ( modelos , etc . )

    Portanto a questão está correta.



ID
239740
Banca
CESPE / CEBRASPE
Órgão
ABIN
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação à engenharia de requisitos, julgue os itens a seguir.

Nos testes de caixa branca, o código-fonte do programa é usado para identificar testes de defeitos potenciais, particularmente no processo de validação, o qual demonstra se um programa atende a sua especificação.

Alternativas
Comentários
  • Teste Estrutural (Caixa Branca) - são testados os caminhos lógicos através do software, fornecendo casos de teste que põem a prova conjuntos específicos de condições e/ou garante que todos os caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez.
        Executa todas as decisões lógicas para valores falsos ou verdadeiros
        Executa todos os laços em suas fronteiras
        Exercita as estruturas de dados internas

    Não demonstra se um programa atende a especificação e sim se o seu funcionamento está correto.

  • Segundo Boehm (1979)

    Validação: envolve checar se o software cumpre com suas obrigações.

    Verificação: envolve checar se o sistema cumpre com seus requisitos funcionais e não funcionais especificados.

    Portanto, a frase correta:

    Nos testes de caixa branca, o código-fonte do programa é usado para identificar testes de defeitos potenciais, particularmente no processo de verificação, o qual demonstra se um programa atende a sua especificação.


  • Enquanto a especificação do software diz respeito ao processo de verificação do software, a expectativa do cliente diz respeito ao processo de validação do software.

    Fonte:http://pt.wikipedia.org/wiki/Teste_de_software
  • O objetivo da Verificação é checar se o software atende a seus requisitos funcionais e não funcionais. Validação, no entanto, é um processo mais geral. O objetivo da Validação é garantir que o software atenda às expectativas do cliente. Ele vai além da simples verificação de conformidade com as especificações, pois tenta demonstrar que o software faz o que o cliente espera que ele faça. A Validação é essencial porque as especificações de requisitos nem sempre refletem os desejos ou necessidades dos clientes e usuários do sistema.     Fonte: Ian Sommerville, Engenharia de Software, 9ª Edição.     Portanto,

    Nos testes de caixa branca, o código-fonte do programa é usado para identificar testes de defeitos potenciais, particularmente no processo de validação Verificação,o qual demonstra se um programa atende a sua especificação.
  • Prezados,

    Relembrando para não esquecer :
    Verificação identifica se o software foi feito corretamente, se ele atente aos requisitos documentados. 
    Validação identifica se o software correto foi feito, se ele atendeu as expectativas do cliente.

    O inicio da questão está correto, entretanto é o processo de verificação que demonstra que o programa atende a sua especificação.

    Portanto a questão está errada.

  • A diferença entre verificação e validação é explicada de forma sucinta com as seguintes perguntas (Boehm, 1979):

    Verificação: estamos construindo certo o produto?
    Validação: estamos construindo o produto certo?


ID
240514
Banca
FCC
Órgão
TRT - 22ª Região (PI)
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Em termos de teste de sistemas, são técnicas utilizadas para verificar a operação correta do sistema em relação a casos inválidos ou inesperados de entrada. Trata-se de técnicas

Alternativas
Comentários
  • Puts, errei a questão.  Não percebi que ele falou de TECNICA, e respondi como se fosse tipo de teste. Coloquei da caixa preta. letra E)

    Pelo que entendi existem duas Técnicas de Teste ( Funcionais e Não-Funcionais).

    A Técnica funcional aborda os seguintes tipos de testes:
    - Teste Caixa Branca
    - Teste Caixa preta
    - Teste Caixa Cinza
    - Teste  de Regressão

    A Técnica não-funcional aborda as seguintes:
    - Teste  de desempenho
    - Teste de carga
    - Teste de usabilidade
    - Teste de confiabilidade
    - Teste de recuperação

    PS: Alguém corrija-me se eu estiver errado ou acrescente se necessário.
  • Acho que é isso mesmo.

    http://pt.wikipedia.org/wiki/Teste_de_software
  • Pelo que pesquisei, caixa-preta, caixa-branca e caixa-cinza também são técnicas para testar software, mas são técnicas funcionais.

    Em contraste às técnicas funcionais, que verificam a operação correta do sistema em relação a sua especificação, as técnicas não funcionais verificam a operação correta do sistema em relação a casos inválidos ou inesperados de entrada. É uma forma de testar a tolerância e a robustez do software em lidar com o inesperado.

    Fonte: http://pt.wikipedia.org/wiki/Teste_de_software
  • Quem errou essa questão estudou pelo Pressman ou Sommerville,
    quem acertou estudou pelo Wikipedia (bibliografia fundamental para FCC)
  • Wikipedia bibliografia fundamental para FCC? Que coisa..
  • Eu ainda não consegui classificar os tipos de testes, estágios ou níveis de testes, técnicas de testes, ... Ora, o que são técnicas para alguns são chamados de tipos de testes para outros; ora é o inverso. Confesso que estou confuso. A classficação que havia feito até esta questão era a seguinte:
    Técnicas: teste Operacional, teste negativo-positivo, teste de regressão, teste de caixa branca, teste de caixa preta, teste alfa, teste beta.
    Tipos de testes: teste de benchmark, teste de funcionalidade, teste de confiabilidade, teste de desempenho, teste de suportabilidade, ...
    Para mim, as técnicas eram aplicadas para tipos de testes específicos.
    Devido a essa minha classificação, respondi como sendo teste de caixa-preta. Errei!!!
    Após a ler o post do colega acima, concordo que casos inválidos ou inesperados de entrada, validam a robustez e a confiabilidade do sistema em relação a recuperação contra erros e falhas e dessa forma não é um teste para validar requisitos FUNCIONAIS, mas para validar requisitos NÃO FUNCIONAIS.
  • Essa FCC é uma praga (1).

    Comportamento esperado é um tipo de requisito funcional. 

    "O teste caixa-preta tenta encontrar erros nas seguintes categorias:...(4) erros de comportamento ou de desempenho"
    Pressman, 7ed, pag 439.


    "Os termos teste funcional e teste estrutural são às vezes usados em lugar de teste caixa-preta e teste caixa-branca, respectivamente."
    Pressman, 7ed, pag 431.
  • Essa é uma questão que não vale a pena estudar, visto que foi tirada da wikipedia, é um conceito errado, não baseado em nenhuma literatura de referência como Pressman ou Sommerville. Cabia a anulação, com certeza.
  • Assim fica difícial, nem a própria FCC estabeleceu um critério para cobrar fases, níveis, técnicas, etc. Olhem essa questão:

    Q62908 A técnica de teste de software, também chamada de comportamental, é a técnica de: R: Caixa-Preta.
  • Pra mim não existe a técnica não-funcional, mas sim teste de caixa-preta. Questão passível de anulação!!!

  • Tem que ser criada uma lei que obrigue as bancas a colocar a bibliografia das provas. Tem que ler livros, wikipédia e a mente do avaliador...

  • Questão ridicula

  • FCC querendo ser CESPE? k k k k 

    Há duas 'Técnicas' de Teste : Funcionais e Não-Funcionais.

  • Teste Funcional: Verificação da consistência entre o produto implementado e os requisitos funcionais.
    Teste não-funcional: Verificar as características de como o sistema trabalha. Teste de carga, interoperabilidade, manutenibilidade...
    Fonte: http://www.great.ufc.br/ctqs/images/arquivos/NTTteste.pdf


  • Boa Josepe !!!


ID
249460
Banca
CESPE / CEBRASPE
Órgão
DETRAN-ES
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens de 81 a 94, acerca de princípios, métodos, técnicas
e processos da engenharia de software e de bancos de dados.

Desenho orientado a modelagem de dados, testes de estresse e o estilo de arquitetura de software cliente-servidor são algumas das técnicas comumente empregadas em projetos de interfaces com o usuário.

Alternativas
Comentários
  • Questão errada!
    Testes de estresse visam conhecer a robustez do sistema como um todo ou em determinado aspecto. Em outras palavras: O sistema é submetido a elevadas cargas de acesso, dados ou processamento (podem ser os três juntos ou qualquer combinação entre eles - de acordo com a necessiadade do negócio) para ver até onde ele suporta responder. E desenho orientado a modelagem de dados, diz respeito a persistência dos dados, como eles serão armazenados.
  • O correto seria testes de usabilidade e comunicabilidade
  • interfaces com o usuário--> testes de usabilidade e comunicabilidade


ID
260233
Banca
FCC
Órgão
TRT - 4ª REGIÃO (RS)
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

O teste de componentes compostos concentra-se, princi- palmente, em verificar se

Alternativas
Comentários
  • Esta questão trata dos níveis de teste sendo:

    Unidade: Teste realizado com os componentes individuais de um software, na maioria das vezes feito pelo desenvolvedor.
    Integrado: Teste realizado com a finalidade de expor defeitos nas interfaces e nas interações entre componentes ou sistemas integrados.
    Sistema: Testa um sistema integrado para verificar se ele atende aos requisitos especificados. Realizado pelos testadores.
    Aceitação: Teste formal relacionado à necessidade dos usuários e aos requisitos e processos de negócio. Realizado pelos usuários/stakeholders para estabelecer a confiança no sistema.

  • Teste de interfaces

    Muitos componentes em um sistema não são funções ou objetos simples, mas sim componentes compostos constituídos de vários objetos que interagem. Conforme explicado no Capítulo 19, que aborda a engenharia de software baseada em componentes, a funcionalidade desses componentes é acessada por meio de suas interfaces definidas. O teste dos componentes compostos concentra-se principalmente em se a interface de componente se comporta de acordo com sua especificação.

    Sommerville 8ª edição página 362
  • Lendo o livro do Pressman eu não conseguir achar um sinônimo para teste de unidade = teste de componente, se alguém puder colocar a fonte de alguma informação relacionado a isso agradeço.

    Bom acertei essa questão pensando no conceito de Teste de unidade, por quê?  Porque o teste de unidade é você pegar um módulo ou componente e realizar um teste separadamente do mesmo podendo ser uma classe ou um método. No teste de unidade a interface de um módulo é testada para assegurar que as informações fluam corretamente para dentro e para fora da unidade de programa que esta sendo testada. 
    baseado nisso marquei letra C
  • Bruno Dias,

    Segundo Sommerville (9ed, pag 151) "Testes de componentes compostos devem centrar-se em mostrar que a interface de componente se comporta de acordo com sua especificação. Você pode assumir que os testes unitários sobre os objetos indivi­duais dentro do componente já foram concluídos."


    De acordo com Pressaman (7ed, pag 409)"O teste de integração é uma técnica sistemática para construir a arquitetura de software ao mesmo tempo que conduz testes para descobrir erros associados com as interfaces. O objetivo é construir uma estrutura de programa determinada pelo projeto a partir de componentes testados em unidade."


    Portanto podemos concluir que Testes de componentes podem ser chamados de teste de integração, dependendo do autor utilizado.


    Isso não impede que testes de interface também sejam realizados em testes unitários.




ID
267874
Banca
CESPE / CEBRASPE
Órgão
TRE-ES
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Considerando que a aplicação de testes em um programa possibilita
verificar se ele atende à sua especificação e se realiza o que o
cliente deseja, julgue os itens subsecutivos, relativos a testes de
software.

O teste de validação tem por finalidade encontrar defeitos e inconsistências no programa com relação a sua especificação.

Alternativas
Comentários
  • >> http://learn.uci.edu/oo/getOCWPage_utf8.php?course=OC0105013&lesson=008&topic=3&page=1
  • Verification and validation are not the same thing.

    Verification shows conformance with specification;

    Validation shows that the program meets the customer’s needs

    Fonte: Sommerville, Edição 6, Cap. 19
  • O objetivo da Verificação é checar se o software atende a seus requisitos funcionais e não funcionais. Validação, no entanto, é um processo mais geral. O objetivo da Validação é garantir que o software atenda às expectativas do cliente. Ele vai além da simples verificação de conformidade com as especificações, pois tenta demonstrar que o software faz o que o cliente espera que ele faça. A Validação é essencial porque as especificações de requisitos nem sempre refletem os desejos ou necessidades dos clientes e usuários do sistema.


    Fonte: Ian Sommerville, Engenharia de Software, 9ª Edição.


    Portanto,

    O teste de validação Verificação tem por finalidade encontrar defeitos e inconsistências no programa com relação a sua especificação.
  • Pessoal, sou novo no assunto e ainda estou com dúvida. 

    O cespe assim considerou: 
    O resultado de um teste de verificação indica se o software desenvolvido corresponde aos requisitos especificados.
    errado
     
    O teste de validação tem por finalidade encontrar defeitos e inconsistências no programa com relação a sua especificação.
    errado

    Para mim as duas questões referem-se a mesma coisa. Como podem ambas estarem erradas? Importante lembrar que as duas questões são do mesmo concurso, entretanto para cargos diferentes (uma para Analista e a outra para Técnico). Quem puder ajudar agradeço.

    [editado]

    e ainda considerou isso:
    Considerando-se o programa final como caixa preta, a validação dinâmica, ou teste, pode ser utilizada para identificar a ocorrência de defeitos no programa ou para confirmar se ele atende aos requisitos estabelecidos.
    certo
  • Validação: O sistema é válido? Atende o que o cliente precisa?
    Verificação: O sistema foi construido conforme os requisitos?  Atende as especificações?
  • Concordo com o Thiago, para mim eles consideraram a mesma definição para duas coisas diferentes.
  • Thiago e Tyler, concordo com vocês. Na minha opinião a primeira questão indicada pelo Thiago (O resultado de um teste de verificação indica se o software desenvolvido corresponde aos requisitos especificados.) está com o gabarito errado, pois na minha opinião a afirmativa está 'correta'.

    Já esta questão que estamos analisando (O teste de validação tem por finalidade encontrar defeitos e inconsistências no programa com relação a sua especificação.) está com o gabarito correto. Thiago e Tyler

    O 'engraçado' é que o cespe não alterou o gabarito, considerando questões divergentes como tendo a mesma resposta. Foda.
  • O teste de validação não "tem por finalidade encontrar defeitos e inconsistências" e sim garantir que o software esteja sendo construído de acorodo com o que o cliente realmente espera.
  • Uma dica só para ajudar:

    Quando se falar sobre requisitos, então refere-se a
    validação.

    Quando se falar sobre funçoes ou especificações, então refere-se a
    verificação.

    Espere ter ajudado, bons estudos
  • Verificação: analisar se está de acordo com a especificação.

    Validação: analisar se está de acordo com o que o cliente quer.

    Mas, ai pode vir alguém e perguntar isso não é a mesma coisa? Respondo, não. Pois, a especificação pode estar equivocada, logo o cliente não estaria satisfeito se estivesse de acordo com a especificação. Por isso, que a verificação antecede a validação.

ID
267880
Banca
CESPE / CEBRASPE
Órgão
TRE-ES
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Considerando que a aplicação de testes em um programa possibilita
verificar se ele atende à sua especificação e se realiza o que o
cliente deseja, julgue os itens subsecutivos, relativos a testes de
software.

Inspeções de programa correspondem a um teste de verificação amplamente utilizado, que deve ser realizado no momento em que o programa está sendo executado.

Alternativas
Comentários
  • Inspeção do programa = Inspeção do código (leitura) = Verificação.
    É importante ter em mente a diferença de teste:
    Verificação = Teste estático (sem execução o programa).
    Validação = Teste dinâmico (com execução o programa).
  • Inspeções não sao testes, e sim uma revisão técnica formal. Ela é realizada em todos os artefatos gerados durante o desenvolvimento de software.
  • Software inspections: Concerned with analysis of the static system representation to discover problems (static verification)
     • May be supplement by tool-based document and code analysis

    Software testing: Concerned with exercising and observing product behaviour (dynamic verification)
     • The system is executed with test data and its operational behaviour is observed

    Fonte: Sommerville, 6 Edição Capitulo 19

  • As inspeções centram-se principalmente no código-fonte de um sistema, mas qualquer representação legível do software, como seus requisitos ou modelo de projeto, pode ser inspecionada. Ao inspecionar um sistema, você usa o conhecimento do sistema, seu dominio de aplicação e a linguagem de programação ou modelagem para descobrir erros.
    Existem três vantagens da inspeção de software sobre os testes:
           1 - Durante o teste, erros podem mascarar (esconder) outros erros. Quando um erro conduz saídas inesperadas, você nunca tem certeza se as anomalias seguintes são devidas a um novo erro ou efeitos colaterais do erro original. Como a inspeção é um processo estático, você não precisa se preocupar com as interações entre os erros. Consequentemente, uma sessão unica de inspeção pode descobrir muitos erros no sistema.
            2 - Versões incompletas de um sistema podem ser inspecionadas sem custos adicionais. Se um programa é incompleto, você precisa desenvolver dispositivos de teste especializados para testar as partes disponiveis. Isso, obviamente, aumenta os custos de desenvolvimento do sistema.
            3 - Bem como a procura por defeitos de programa, uma inspeção pode considerar outros atributos de qualidade de um programa, como a conformidade com os padrões, portabilidade e manutenibilidade. Você pode procurar ineficiencias, algoritmos inadequados e um estilo de programção que poderiam tornar o sistema de dificil manutenção.
    As inspeções de programa são uma ideia antiga, e vários estudos e experimentos demonstraram que as inspeções são mais eficazes na descoberta de defeitos do que os testes de programa. Fagan (1986) relatou que mais de 60% dos erros em um programa podem ser detectados por meio de inspeções informais de programa. No processo Cleanroom (PROWELL et al, 1999), afirma que mais de 90% dos defeitos podem ser descobertos em inspeções de programas.

    Fonte: Ian Sommerville, Engenharia de Software, 9ª Edição.

    Logo, se a inspeção de programa centra-se no Código-fonte, sendo assim um processo estático, ela não vai ser executada quando o sistema está rodando.
  • Resumindo...

    Inspeções de programa correspondem a um teste de verificação amplamente utilizado (CERTO), que deve ser realizado no momento em que o programa está sendo executado (ERRADO: Inspeção = verificação estática).


    Bons estudos!




ID
267883
Banca
CESPE / CEBRASPE
Órgão
TRE-ES
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Considerando que a aplicação de testes em um programa possibilita
verificar se ele atende à sua especificação e se realiza o que o
cliente deseja, julgue os itens subsecutivos, relativos a testes de
software.

O teste de partições caracteriza-se por ser um projeto de caso de teste, em que o conhecimento da estrutura do programa é utilizado para projetar testes que verificam todas as partes desse programa.

Alternativas
Comentários
  • O teste de particionamento de equivalência é uma das técnicas de teste caixa-preta, por tanto não utiliza o conhecimento da estrutura do programa para planejar sua estratégia. Nesse teste, divide-se o domínio de entrada de um programa em classes de dados, das quais os casos de teste podem ser derivados.
    http://ensaiosdeqa.blogspot.com/2010/03/particao-por-equivalencia.html
  • P/ complementar...

    Principais técnicas de caixa-preta:

    - Testes baseados em grafos:Graph-based testing methods. Toda aplicação é construída por “objetos”. Essa técnica identifica todos estes objetos e gera gráficos para representá-los. Os objetos e relacionamentos são testados para descobrir erros e comportamentos inesperados.

    - Partição de equivalência: é um método que divide o domínio de entrada em categorias de dados. Cada categoria revela uma classe de erros, permitindo que casos de testes na mesma categoria sejam eliminados sem que se prejudique a cobertura dos testes.

    - Analise de valor limite: Em geral, erros nas fronteiras do domínio da entrada são mais frequentes do que nas regiões centrais. A análise de valor limite é uma técnica p/ seleção de casos de teste que exercitam os limites. O emprego dessa técnica deve ser complementar ao emprego da partição de equivalência. Assim, em vez de se selecionar um elemento aleatório de cada classe de equivalência, selecionam-se os casos de teste nas extremidades de cada classe.

    - Matriz ortogonal

    Alternativa: Errada

  • Segundo Pressman (7ed, pg 463), o teste de partição reduz o número de casos de teste necessários para simular a classe de maneira muito semelhante ao particionamento de equivalência para software tradicional. As entradas e saídas são classificadas e os casos de teste projetados para exercitar cada categoria.

  • Apesar de Pressman afirmar que o teste de partição é um teste de caixa-preta o sommerville afirma que pode ser caixa-preta ou caixa-branca. Como exemplo, nesse último caso, pode  olhar código e notar que alguns valores são tratados como exceção. Com isso, você cria uma partição de exceção. Para mim, um erro é dizer que verifica todas as partes do programa. Não, apenas aquela partição. 

  • O problema em não mencionar o nome do teste completo dá margens para várias interepretações. "Teste de partições" e "Testes de equivalência" podem ter significados totalmente distintos. 

  • Teste de Unidade é teste de caixa branca.

    Teste de particionamento de equivalência é teste de caixa preta.

    Tipos de Teste de Caixa-Preta (Back-Box)

    • Graph-Based Testing Methods
    • Equivalence Partitioning
    • Boundary Value Analysis
    • Orthogonal Array Testing

    Fonte: Pressman (7ª Edição)


ID
276733
Banca
ESAF
Órgão
CVM
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Uma ferramenta de automação de teste

Alternativas
Comentários

ID
276736
Banca
ESAF
Órgão
CVM
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

São axiomas em risco

Alternativas
Comentários
  • Teoricamnte, É possível testar um programa completamente, como no teste da complexidade ciclomática, onde  todos os caminhos independentes de um programa são exercitados.
  • Que questão esquisita. Acredito que seja possível testar um programa completamente. Se for um programa simples ele poderá ser testado completamente.
  • Concordo com o comentário acima que seja possível testar completamente um software muito pequeno. 

    No entanto, existe alguns principios de teste de software (axiomas como se refere o enunciado da questão), e um deles é: É impossível testar um programa completamente.

    uma boa referência sobre essa questão está em: http://blog.prasabermais.com/2011/07/10/axiomas-sobre-os-testes-de-software/

    Descrições desse princípio:

    Teste Exaustivo não são possíveis.
    A quantidade de permutações de caminhos, mesmo para um programa de tamanho moderado, é excepionalmente grande. Por essa razão, é impossível  executar todas as combinações de caminhos durante o teste. É possível, no entanto, cobrir adequadamente a lógica do programa e garantir que todas as condições do projeto, em nível de componente, tenham sido exercitadas.
    Segundo Pressman (6 edicao - pág. 94)

    Teste completo é impossível.
    Testes completo, que cobre todas as combinações possíveis de dados a fim de assegurar que nenhuma situação não testada possa surgir após o lançamento do software. Exceto em aplicações extremamente simples, o número de combinações possíveis de dados é proibitivamente alta, é mais eficaz e eficiente para os testadores foco sobre os riscos e prioridades, de modo que os testes são direcionados para as necessidades de testes.
    (fonte: http://www.knowledgetrain.co.uk/iseb-software-testing-seven-principles.php)


    Teste nunca pode encontrar 100% dos erros incluídos.
    Haverá sempre um resto de erros remanescentes que não pode ser encontrado.
    Cada tipo de teste vai encontrar um tipo diferente de erros.
    (fonte: http://www.the-software-experts.de/e_dta-sw-test-principles.htm)
  • A questão queria tratar os axiomas de teste.

    Fonte: https://www.cs.drexel.edu/~spiros/teaching/.../*testing*
    -realities.ppt

    Software testing axioms

    1. It is impossible to test a program completely.
    2. Software testing is a risk-based exercise.
    3. Testing cannot show the absence of bugs.
    4. The more bugs you find, the more bugs there are.
    5. Not all bugs found will be fixed.
    6. It is difficult to say when a bug is indeed a bug.
    7. Specifications are never final.
    8.Software testers are not the most popular members of aproject.
    9. Software testing is a disciplined and technical profession.

    Parenthesis:What is an axiom anyway?

    • An axiom is a sentence or proposition that is not
    proved or demonstrated and is considered as
    obvious or as an initial necessary consensus for a
    theory building or acceptation.

    • Therefore, it is taken for granted as true, and serves
    as a starting point for deducing and inferring other
    (theory dependent) truths.

    (Resposta dada pelo Thiago na Timasters)

ID
276742
Banca
ESAF
Órgão
CVM
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a opção correta.

Alternativas
Comentários
  • Pairwise
    "Esta técnica é baseada na observação de que 
    a maioria das falhas é causada pela combinação de apenas dois fatores(http://www.pairwise.org/). Em outras palavras, a causa da maioria dos bugs encontrados quando temos várias condições (ou variáveis) de entrada se deve ao conflito entre apenas duas delas. Por exemplo, se temos cinco condições de entradas para que o fluxo de um determinado workflow prossiga, caso uma falha seja encontrada, existe, aproximadamente, 95% de chance do motivo da falha ter sido causada pelo conflito entre duas condições apenas. Dificilmente alguma falha é resultante do conflito de três condições, muito menos de quatro ou cinco delas. Dessa forma, conclui-se que não é necessário testar todas as combinações. Em uma análise sobre testes realizada pelo NIST (www.nist.gov/) em 2003, apenas três entre 109 relatórios de testes indicaram que o conflito entre mais de duas combinações foi o responsável pela falha. Foi dessa estatística que encontrei o 95% citado acima."
    Fonte: 
    http://www.testexpert.com.br/?q=node/1266
  • Alguém sabe o que significa os outros termos acima? Nunca ouvi falar !!
  • alguém consegue comentar os outros testes?
    pois nem o google ta sabendo me responder.
  • Não existe os testes de valor Referenciado, Blockwise testing, Parserwork testing e teste por Relação. São todos inventados pela banca para confundir o candidato.

     

    d) CORRETO. 'Teste Combinatório' chamada 'Pairwise Testing', também conhecida como 'All-Pairs Testing'. O Teste de Pares (ou Pairwise Testing) como uma técnica de design de teste de caixa preta em que os casos de teste são projetados para executar todas as combinações possíveis de cada par de parâmetros de entrada.


ID
276745
Banca
ESAF
Órgão
CVM
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Teste de Equivalência de Classe é

Alternativas
Comentários
  • A idéia das classes de equivalência no teste de software é que, já que não podemos testar todos os casos existentes, vamos dividí-los em classes, de modo que os casos dentro de cada classe sejam "equivalentes", o que nos permitirá testar apenas um subconjunto deles, mantendo a representatividade.

  • É um teste simples, todos fazem, mas alguns não conhecem o nome.

    Se você tem um campo que deve aceitar apenas valores entre 10 e 70.   Você não precisa testar todos os números para garantir que a validação esta funcionando. Você escolhe um conjunto menor que 10 (invalido), um conjunto de números entre 10 e 70 (válidos) e um conjunto maior. Desse forma você garante que a validação esta correta. E utiliza 3 Classes de Equivalência!

ID
277297
Banca
CESPE / CEBRASPE
Órgão
TRE-ES
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Testes ajudam a descobrir erros ocorridos durante o projeto e a construção de software. As estratégias de teste devem ser planejadas de forma adequada, e ferramentas de teste podem ser utilizadas para tal fim. A esse respeito, julgue os itens subsequentes.

No plano de teste, um documento de nível gerencial, definem-se como o teste vai ser realizado, quem vai executar os testes, o prazo estimado e o nível de qualidade esperado.

Alternativas
Comentários
  • No ciclo de vida do projeto de teste segundo a IEEE 829 o plano de teste apresenta o planejamento para execução do teste, incluindo a abrangência, abordagem, recursos e cronograma das atividades de teste. Além disso identifica as tarefas a serem realizadas e os riscos associados.
  • Segundo Pressman: "Definirem  explicitamente os objetivos do  teste.  Os objetivos específicos do teste deverão ser definidos em term os mensuráveis.  Por exemplo,  a eficiência do teste,  a abrangência do teste,  o tempo médio entre falhas,  o  custo para localizar e  corrigir defeitos,  densidade de defeitos restantes ou  frequência  de ocorrência e horas  de  trabalho em  testes  deverão ser definidos dentro do plano de teste."
  • Segundo o RUP, o Plano de teste é de responsabilidade do Gerente de teste. Logo é correto dizer que é um documento no nível gerencial. Gabarito "Certo"


ID
277303
Banca
CESPE / CEBRASPE
Órgão
TRE-ES
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Testes ajudam a descobrir erros ocorridos durante o projeto e a construção de software. As estratégias de teste devem ser planejadas de forma adequada, e ferramentas de teste podem ser utilizadas para tal fim. A esse respeito, julgue os itens subsequentes.

O resultado de um teste de verificação indica se o software desenvolvido corresponde aos requisitos especificados.

Alternativas
Comentários
  • Esse seria teste de validação e não de verificação.

    Verificação = estou fazerndo o software da maneira correta?

    validação = o software foi desenvolvido de forma correta?
  • Verificacão: Se refere ao conjunto de atividades que garante que o software implementa corretamente uma função específica. Estamos construído o produto corretamente?Validação: Se refere ao conjunto de atividades que garante que o software construido corresponde aos requisitos do cliente. Estamos construindo o produto correto?
  • Alguem possui uma explicacao BEM fundamentada sobre o gabarito dessa questao?

    Sommerville (edicao 8, pag 353)
    Verificação se destina a mostrar que um programa atende à sua especificação.
    Pressman (edicao 6, pag 289)
    Verificação se refere ao conjunto de atividades que garante que o software implementa corretamente uma função específica. Validação se refere a um conjunto de atividades diferentes que garante que o  SW construído corresponde aos requisitos do cliente¹.
    ¹Deve ser observado que ha uma forte divergencia de opiniao sobre que tipos de teste constituem "validacao". Algumas pessoas acreditam que todo teste é verificação e que validação é conduzida quando requisitos são revisados e aprovados, e posteriormente, pelo usuário, quando o sistema estiver operacional.

    Bom, acredito que talvez o examinador tenha ido ao ¹ para realizar essa questão.
  • O colega acima foi feliz na explicação.

    Verificação: será que o software fou construído corretamente (atende ao que foi planejado, por exemplo)?
    Validação: será que o software atende ao cliente?

    Você pode ter um software validado pelo cliente, mas que não atende ao que foi planejado.
  • Pressman - 6ª edição - página 289.

    Verificação -> refere-se ao conjunto de atividades que garante que o software implementa corretamente uma função específica (Estamos contruindo o produto corretamente?)

    Validação -> refere-se a um conjunto de atividades diferente que garante que o software construído corresponde aos requisitos do cliente (Estamos construindo o produto certo?).
  • Verificação - verifica o processo
    Validação - verifica o produto
  • Sommerville vs Pressman

    O CESPE costuma ir mais na onda do Sommerville...
  • Acredito que o examinador viajou muito na resposta dessa questão. Pois entende-se que ele quiz dizer que a atividade que indica se o software desenvolvido corresponde aos requisitos especificados é a de validação. No entanto, através da literaturas consagradas sobre o assunto, no caso Presmman e Sommervile, vimos que essa atividade se chama verificação.
  • Sem chances de eu concordar com o gabarito.

    Validação é referente ao fato de construção de requisitos (sistema) coerente com a necessidade real do negócio.

    Verificação é referente ao fato de construirmos corretamente os requisitos especificados (independente de estes estarem coerentes com a necessidade real do negócio ou não).

    Se a resposta pra essa questão for realmente "errado", boa parte das questões que já respondi sobre Testes de Software estão com o gabarito incorreto.
  • Interpretei da seguinte forma:
    O resultado de um teste de verificação indica se o software desenvolvido corresponde aos requisitos especificados. (ERRADO)

    o resultado de UM teste diz pode indicar apenas se o software desenvolvido corresponde ao requisitos especificados relacionados a ESSE teste.

    O resultado de TODOS TESTES DE VERIFICAÇÃO indicam se o software desenvolvido corresponde aos requisitos especificados. (CERTO)

     

  • VERIFICAÇÃO X VALIDAÇÃO

    Verificação: não se preocupa com o cliente,  mas com a especificação.
     

    Se eu contratei um arquiteto para projetar uma casa de três quartos e ele me apresentou uma proposta correspondente ao que eu solicitei (houve validação, pois o arquiteto preocupou-se com as necessidades e requisitos do cliente, portanto, não houve rejeição ao projeto). Depois da aprovação do projeto, vem a fase do projeto executivo, e depois a fase da construção. Se aquilo que o arquiteto projetou, foi realmente construído, se no piso foi colocado cerâmica conforme a especificação, se a parede tem o pé direito duplo em uma parte da sala, ou se na bancada da cozinha foi colocada granito conforme a especificação do projeto, então estamos falando de VERIFICAÇÃO. Estou realmente verificando se aquilo que foi especificado no projeto, está sendo construído ou foi construído.



    A validação tem o objetivo de avaliar se o que foi entregue atende as expectativas do cliente. Ou seja, se os requisitos, independente do que foi planejado, estão sendo implementados para atender a regra de negócio do cliente, se o sistema é realmente aquilo que o cliente quer e está pagando para ter. A validação final do sistema é realizada pelo próprio cliente ou usuário. Portanto, a validação tem como foco a análise de requisitos segundo o cliente.
    Se eu contratei um arquiteto para projetar uma casa de três quartos e ele apresenta um projeto de dois quartos, não há validação. O cliente rejeita o projeto. A regra do negócio era um projeto  onde consta três quartos. Se um casal tem dois filhos, sendo um menino e uma menina, por exemplo, uma casa de dois quartos não adequa às necessidades do casal. Da mesma forma, se fosse apresentada uma solução com 4 quartos, atenderia à necessidade quanto ao número de filhos, mas não se adequaria a sua realidade financeira, ou às suas expectativas.

    Ficou claro?













































     

  • O resultado de um teste só pode indicar a existência de um bug e não que o software está livre de bugs. Seguindo essa lógica, o resultado de um teste de verificação indica se o software desenvolvido NÃO corresponde aos requisitos especificados. Não tem como um teste garantir que o software corresponde 100% aos requisitos especificados.
  • "Essa questão é famosa e eu não concordo com seu gabarito. O Sommerville fala que o teste de verificação é para checar as especificações (requisitos) do produto. Ou seja, a questão deveria estar correta." (Professor Fernando Pedrosa)

  • Essa questão é bem polêmica. Acho que o CESPE se baseou na seguinte literatura: "Técnicas para Gerenciamento de Projetos de Software" Por JOSÉ CARLOS CORDEIRO MARTINS.

    Link: https://books.google.com.br/books?id=Axl2RZQdE68C&pg=PA16&lpg=PA16&dq=plano+de+teste+documento+de+n%C3%ADvel+gerencial&source=bl&ots=Xg0aY7n5Wl&sig=DT8fYbBRCtNZSGr00lZjI9x58hk&hl=pt-BR&sa=X&ei=7ytaVejrHYOUNqj_gcgP&ved=0CB4Q6AEwAA#v=onepage&q=plano%20de%20teste%20documento%20de%20n%C3%ADvel%20gerencial&f=false

    Nessa literatura diz o seguinte: " ...Depois vem o teste de validação, que valida se o software implementado corresponde aos requisitos especificados."

  • Na minha opinião esta correta 


  • Requisitos em que sentido ? Se forem os funcionais e não funcionais estão correto.  Questão do estagiário.

  • E o estagiário examinador ataca novamente!


ID
280867
Banca
INSTITUTO CIDADES
Órgão
AGECOM
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

A função de um Testador de software pode ser assinalada nas seguintes alternativas, EXCETO:

Alternativas

ID
280894
Banca
INSTITUTO CIDADES
Órgão
AGECOM
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Uma vez implementado o código de uma aplicação, o mesmo deve ser testado antes da entrega do produto de software ao seu cliente, a fim de que sejam detectados possíveis erros. Com relação a Teste de Aplicação, marque a alternativa INCORRETA:

Alternativas
Comentários
  • d) ERRADO. O planejamento dos testes permite a identificação dos itens e funcionalidades que deverão ser testados, quem são os responsáveis e quais os riscos envolvidos. Ou seja, permite definir o escopo, o custo e o prazo para as atividades de teste do projeto. Para a realização desta etapa, os responsáveis devem tomar como referência os requisitos e suas prioridades. Ainda na etapa de planejamento serão definidas estimativas, estratégias e técnicas de teste.


ID
280924
Banca
INSTITUTO CIDADES
Órgão
AGECOM
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

O teste de integração constitui-se em identificar erros associados às interfaces entre os módulos quando esses são integrados para construir a estrutura do software que foi estabelecida na fase de projeto. Com relação a teste de integração, analise as seguintes afirmativas:

I. O teste de integração é o processo de verificar se os componentes do sistema, juntos, trabalham conforme descrito nas especificações do sistema e do projeto do programa.
II. O teste de integração é uma estratégia de integração que deve responder a três questões: quais componentes são focados pelos testes de integração; em que seqüência as interfaces de componentes deverão ser exercitadas e qual técnica de teste será empregada para exercitar a interface.
III. Um stub é a implementação parcial de um componente.

Podemos afirmar corretamente que:

Alternativas

ID
280933
Banca
INSTITUTO CIDADES
Órgão
AGECOM
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Teste de unidade é toda a aplicação de teste nas assinaturas de entradas e saídas de um sistema. Consiste em certificar dados válidos e inválidos via I/O (entrada/saída) sendo aplicado por desenvolvedores ou analistas de teste. Com relação a teste de unidade, assinale a alternativa correta.

Alternativas
Comentários
  • a) ERRADO. Uma unidade é a menor parte testável de um programa de computador.

    c) ERRADO. Os Procedimentos, também conhecidos como rotinas, subrotinas, métodos ou funções (que não devem ser confundidas com funções matemáticas, mas são similares àquelas usadas na programação funcional) simplesmente contêm um conjunto de passos computacionais a serem executados.

    d) ERRADO. Inválidos: São entradas e saídas de dados não comuns ao sistema.

    e) ERRADO. Domínios pode ser um campo, uma assinatura, um I/O, ou qualquer tipo de local que receba valores externos ao sistema.


ID
280951
Banca
INSTITUTO CIDADES
Órgão
AGECOM
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Teste de caixa-branca é uma técnica de teste que utiliza a perspectiva interna do sistema para modelar os casos de teste. Com relação ao Teste de caixa- branca, marque a alternativa correta.

Alternativas
Comentários
  • a) Como os testes são baseados na implementação ao invés da interface, caso a implementação seja alterada, o teste dificilmente será.

    Como os testes são baseados na implementação ao invés da interface, caso a implementação seja alterada, o teste provavelmente também terá que ser.

     

    b) O Teste de caixa-branca é aplicável nas fases de unidade, integração, regressão e sistema do processo de teste. Geralmente é utilizado na fase de integração.

     O teste de caixa-branca é aplicável nas fases de unidade, integração, regressão e sistema do processo de teste, e geralmente usado na fase de unidade.

     

    c) Estratégias usadas no teste de caixa-branca incluem o teste de fluxo de controle, fluxo de dados e ramificação da execução, além da análise dinâmica.

    Estratégias usadas no teste de caixa-branca incluem o teste de fluxo de controle, teste de fluxo de dados e ramificação da execução, além da análise estática.

     

    d) No teste de software, a perspectiva interna significa basicamente o código fonte.

     

    e) O Teste de caixa-branca utiliza a estrutura de controle do projeto procedimental para derivar casos de uso.

    O teste da caixa branca usa a estrutura de controle do projeto procedimental para derivar casos de teste.

     

    Fontes:

    http://qualityassurance.com.br/?p=6

    https://polisoftware.wordpress.com/2012/11/05/teste-processos/


ID
283762
Banca
FUNIVERSA
Órgão
IPHAN
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Os testes de software são verificações realizadas com o objetivo de avaliar se o software atende às necessidades especificadas ou identificar as diferenças entre os resultados esperados e reais. Com relação aos tipos de testes de software assinale a alternativa correta.

Alternativas
Comentários
  • a) Os testes de caixa branca, ou testes funcionais  teste estrutural ou orientado a lógica, podem também testar “funções ausentes”.
  • Que porcaria de comentário foi esse que essa Fernanda fez em.
  • Letra certa E : A abordagem caixa branca usa a estrutura de controle para derivar casos de testes,ou seja é dependente da lógica de codificação.

    e a abordagem caixa preta focaliza os requisitos funcionais do software,ou seja esses testes são derivados das especificações do programa(software).
  • a) Os testes de caixa branca, ou testes funcionais, podem também testar “funções ausentes”.

    Testes caixa branca analisam o código. Ora, como iremos testar uma função se ela nem existe (ou seja, é "ausente")? O teste caixa preta sim, pois usamos um botão, por exemplo, que, se não fizer nada, pode indicar uma função ausente

    b) Os testes em grande escala corrigem erros de desenho e falhas nos testes de programas.

    Eles apenas detectam e não "corrigem"

    c) Os testes dos recursos funcionais do sistema têm a finalidade de fornecer uma medida sistemática dos recursos de desempenho do sistema e demonstrar a qualidade global do mesmo.

    O desempenho está ligado a requisitos não funcionais

    d) Os testes de aceitação são frequentemente incluídos na bateria dos testes de resistência, e usam estratégia de processamento paralelo.

    Teste de aceitação são feitos para Validação do Cliente. Nada tem a ver com processamento

    e) Testes de caixa preta são independentes da lógica de codificação, mas são derivados das especificações do programa ou componente.

    Correto.



ID
308740
Banca
CESPE / CEBRASPE
Órgão
TJ-ES
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Com referência a engenharia de software e uso de UML para a
modelagem de sistemas, julgue os itens subsecutivos.

O teste de caixa-preta é utilizado quando uma nova versão do software está sendo lançada ou quando um novo ciclo de testes for necessário em paralelo ao desenvolvimento do mesmo.

Alternativas
Comentários
  • A técnica de teste utilizada quando uma nova versão do software está sendo lançada ou quando um novo ciclo de testes for necessário em paralelo ao desenvolvimento do mesmo é chamada de REGRESSÃO.
  • O teste de caixa-preta REGRESSÃO é utilizado quando uma nova versão do software está sendo lançada ou quando um novo ciclo de testes for necessário em paralelo ao desenvolvimento do mesmo.
  • - Testes de regressão:Cada vez que um módulo é adicionado ao sistema, o software muda. Novas entradas e saídas surgem: podem ser executados novos caminhos, a lógica de controle muda. Teste de regressão visa a executar um subconjunto de testes que já foram executados com o intuito de garantir que as mudanças não propagaram efeitos indesejados.

    Alternativa: Errada

  • Não concordo com o gabarito. Um teste de regressão (tipo de teste) pode ser feito utilizando a abordagem caixa-preta. 

    Abordagens: caixa-preta, caixa-branca. Estágios: unidade, integração, aceitação e sistema. Tipos: regressão, smoke testing, recuperação, segurança, carga, desempenho e usabilidade.
  • Corrigindo:

    O teste de regressão é utilizado quando uma nova versão do software está sendo lançada ou quando um novo ciclo de testes for necessário em paralelo ao desenvolvimento do mesmo.


    Bons estudos!


ID
319615
Banca
CESPE / CEBRASPE
Órgão
INMETRO
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Com referência à engenharia de testes e qualidade com foco na identificação de inconsistências entre o propósito de ferramentas de software e as características dos software em desenvolvimento, assinale a opção correta.

Alternativas
Comentários
  • Automação de testes é o uso de software para controlar a execução de testes de software através da aplicação de estratégias e ferramentas, comparando os resultados esperados com os resultados reais. Seus objetivos são a redução do envolvimento humano em atividades manuais, de tempo demandado e de custo final. Ferramentas de automação possuem outros usos, além da medição de performance de aplicações. Elas também podem ser usadas para preparar um ambiente de teste com um grande volume de dados.


ID
319621
Banca
CESPE / CEBRASPE
Órgão
INMETRO
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Considerando uma organização na qual a abordagem de test driven development (TDD) esteja implementada, assinale a opção correta.

Alternativas
Comentários
  • e) Há coerência e inter-relação com os princípios promovidos pela prática da extreme programming (XP).

    Uma das Práticas do XP é o Desenvolvimento Dirigido a Testes (TDD)


ID
319624
Banca
CESPE / CEBRASPE
Órgão
INMETRO
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Com referência ao fortalecimento da capacidade de teste de software em uma organização produtora de software, assinale a opção correta acerca da aplicação de métodos e técnicas de teste de software.

Alternativas

ID
319669
Banca
CESPE / CEBRASPE
Órgão
INMETRO
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a opção correta, com relação às formas adequadas de emprego de testes de software em uma organização.

Alternativas
Comentários
  • Testes de unidade (unitário) testar módulos ou programas individualmente.

    .
    Teste de sistema testar o sistema completo,

    .
    Teste de integração testar ligações e a interação entre todos os módulos do sistema

    .
    Teste de aceitação testar o grau de aceitação por parte dos utilizadores.

    .

    Teste funcional: conhecida como black box, não se importa com a estrutura interna, ou
    seja, qual o algoritmo é usado para implementação da funcionalidade. Tem por objetivo
    garantir que os requisitos e as especificações do sistema tenham sido corretamente
    implementados.

    .
    Teste estrutural: denominada também de white box, olha por dentro, tentando garantir
    que a estrutura interna esteja correta, em relação a aspectos como codificação e
    infraestrutura. Olha para aspectos de segurança, fluxo de dados, saída esperadas entre
    outros.

    .

    Testes de funcionalidade - verifica se determinada funcionalidade tem o comportamento
    esperado. Um exemplo é um teste que tenta gerar a segunda via do boleto. O testador
    clica no botão de segunda via e verifica se o sistema gerou o arquivo corretamente.

    .
    Testes de usabilidade - verifica características não-funcionais de usabilidade. É mais
    usado para compreender e melhorar a interação do usuário com o software, do que para
    encontrar erros. Valida questões como: Satisfação subjetiva dos usuários com o sistema
    e Facilidade de aprendizado para uso do sistema.

    .
    Testes de segurança - avalia as vulnerabilidades do software para determinados tipos de
    ataques.

    .
    Testes de performance ou desempenho - avalia se o sistema atende requisitos de tempo
    de resposta, tempo para entrar em funcionamento e volume de uso.

    .
    Teste de carga (volume/estresse) teste com grande número de dados.


ID
321166
Banca
CESPE / CEBRASPE
Órgão
Correios
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca de engenharia de software, que permite a criação, de maneira econômica e confiável, de software que trabalhe eficientemente em máquinas reais, julgue os próximos itens.

Em um teste de integração, é possível detectar possíveis falhas provenientes da integração interna dos componentes de um sistema. O teste de integração sucede o teste de unidade, no qual os módulos são testados individualmente, e antecede o teste de sistema, em que o sistema completo é testado.

Alternativas
Comentários
  • São as seguintes as fase dos testes:
    1. Teste de unidade: São testadas as menores unidades do software desenvolvido.

    2. Teste de integração: Módulos são combinados e testados juntos.

    3. Teste de validação: Procura demostrar conformidade com os requisitos.

    4. Teste de sistema: è executado o sistema sob o ponto de vista do usuário final, varrendo as funcionalidades em busca de falhas em relação aos objetivos originais.
  • Marquei errado pois para mim o teste de sistema não necessariamente testa o sistema por completo.

    De acordo com o padrão IEEE 829: "Teste de sistema: são realizados pela equipe de testes, visando a execução do sistema como um todo ou um subsistema(parte do sistema), ..."


ID
321367
Banca
CESPE / CEBRASPE
Órgão
INMETRO
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a opção correta acerca da elaboração de estratégias de teste de software.

Alternativas

ID
328102
Banca
FUNCAB
Órgão
IDAF-ES
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a alternativa que NÃO corresponde a um método de teste Caixa Branca.

Alternativas
Comentários
  • TESTE DE MATRIZ ORTOGONAL. Este tipo de teste é aplicado a problemas nos quais o domínio de entrada é relativamente pequeno, mas grande demais para acomodar o teste exaustivo, é útil para encontrar erros associados com falhas de regiões – uma categoria de erros associada com lógica defeituosa em um componente de software.


ID
328630
Banca
FUNIVERSA
Órgão
SEPLAG-DF
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação ao processo, aos modelos e à medição da qualidade de software, bem como aos testes de software, assinale a alternativa correta.

Alternativas
Comentários
  • a) ERRADO. Os testes nem sempre revelam erros conhecidos, já que utilizam modelos determinados para sua execução, como casos e roteiros de testes.

    b) ERRADO. Os recursos compatíveis com o nível de desempenho do software são uma parte do atributo de eficiência para medir a qualidade desse software.

    c) ERRADO. Os testes de software não garantem que o sistema não irá apresentar erros durante a execução.

    d) ERRADO. A maturidade é a medida da frequência com que um software apresenta falhas. Um software mais maduro é aquele que apresenta menos falhas ao longo de um período fixo de tempo.


ID
331552
Banca
FGV
Órgão
FIOCRUZ
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

No que diz respeito aos sistemas de software, teste é um conjunto de atividades que podem ser planejadas antecipadamente e conduzidas sistematicamente. Um tipo I de teste se refere ao conjunto de atividades que garante que o software implementa corretamente uma função específica, associado à construção do produto de forma correta ou não, enquanto um tipo II se refere a um conjunto de atividades diferente que garante que o software construído corresponde aos requisitos do cliente, associado à construção do produto certo. Esses testes do tipo I e II são denominados, respectivamente:

Alternativas
Comentários
  • O conceito de validação, para a engenharia de softwares, é a avaliação do grau em que um sistema de software realmente satisfaz seus requisitos, no sentido de atender às necessidades reais do usuário. Satisfazer requisitos não é o mesmo que estar conforme as especificações de requisitos. A
    especificação de requisitos é uma declaração sobre uma solução particular proposta para um problema, podendo ela atingir ou não os seus objetivos.
    Especificações de requisitos estão suscetíveis a erros, pois são escritas por humanos. As atividades de validação procuram medir o quanto o sistema realmente atinge seus propósitos.

    Para conceituar verificação, podemos afirmar que é a checagem da consistência de uma implementação com uma especificação. A verificação tem o objetivo de avaliar se o que foi planejado realmente foi realizado. Ou seja, se os requisitos, funcionalidades e performence documentados foram implementados.

    Fonte; www.ti24x7.com.br
  • Essa questão foi retirada literalmente do Pressman - Eng. de Software 6ed, cap 13 pag 289

    "Verificação: refere-se ao conjunto de atividades que garante que o software implementa corretamente uma função especifica.
    Estamos construindo o produto corretamente?

    Validção: refere-se ao conjunto a um conjunto de atividades diferentes que garante q o software q foi corresponde aos requisitos do cliente.
    Estamos construindo o produto certo?"

    Bons estudos!!

  • Conceito básico da V&V.

    Verificação: averiguar se está construindo CERTO o produto, ou seja, se segue a especificação. Se apoia, entre outros, em inspeções de código e testes de software.

    Validação: averiguar se está construindo o produto CERTO, ou seja, se vai de encontro com as necessidades do cliente. Se apoia, por exemplo,  na validação por parte do cliente e na inspeção de especificações de software (esta evita ambiguidades, incompleteza, etc).
  • 01) Verificação: Refere-se ao conjunto de atividades que garantem que o SW implementa CORRETAMENTE as funções especificadas.

    "Estamos construindo o produto corretamente? "

    Na verificação eu comparo o que estou implementando com o que foi especificado.


    Validação: Conjunto de atividades que busca garantir que o SW construido implementa o que o cliente desejava.
     
    "Estamos construindo o produto correto?"

    Na validação eu comparo o que estou implementando com o que o usuário solicitou.
  • d-

    Verificação - "fizemos o software corretamente?"

    Validação - "fizemos o software correto?"

    Testes - "tem defeito?"

     

    Em suma, requisitos sao validados; software é verificado. That's all. Ye know on Earth, and that is all Ye need to know.


ID
331555
Banca
FGV
Órgão
FIOCRUZ
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

No que diz respeito aos sistemas de software, o objetivo do teste é encontrar erros, sendo um teste aquele que tem alta probabilidade de encontrar um erro. Assim, um engenheiro de software deve projetar e implementar um sistema ou um produto baseado em computador com “testabilidade” em mente. Ao mesmo tempo, os testes devem exibir um conjunto de características que atinge o objetivo de encontrar a maioria dos erros com um mínimo de esforço. Dentre as características que levam a um software testável, uma pode ser resumida pela frase “Quanto melhor funciona, mas eficientemente pode ser testado”. Se um sistema é projetado e implementado com qualidade em mente, poucos defeitos vão bloquear a execução dos testes, permitindo que o teste progrida sem problemas. Essa característica é definida como:

Alternativas
Comentários
  • “Quanto melhor funciona, mas eficientemente pode ser testado”
    Ao inves de "mas" eu creio que seria "mais".
  • Thiago, você está correto. É "mais" mesmo

    Operabilidade: "Quanto melhor funcionar, MAIS eficientemente pode ser testado." Se um sistema for projetado e implementado tendo em mente a qualidade, haverá poucos defeitos bloqueando a execução dos testes, permitindo que o teste ocorra sem sobressaltos.

    Ref: Roger S. Pressman
  • Operabilidade: quanto melhor funciona, mais eficientemente pode ser testado.
    Observabilidade: o que você vê é o que você testa.
    Controlabilidade: quanto melhor você pode controlar o software, mais o teste pode ser automatizado e otimizado.
    Decomponibilidade: controlando o escopo do teste, podemos isolar problemas mais rapidamente e realizar retestagemmais racionalmente.

    Simplicidade: quanto menos houver a testar, mais rapidamente podemos testá-lo.

    Estabilidade: quanto menos modificações, menos interrupções no teste.

    Compreemsibilidade: quanto mais informações temos, mais racionalmente vamos testar.
  • Os conceitos citados nos comentários acima podem ser encontrados na página 429 do livro do Pressman 7a edição.
  • outro erro bobo, mas não é funciona e sim funcionaR
    são coisas bobas, mas na hora da prova, se você não souber bem, acaba descartando a questão por achar que ela está errada, já que a desinencia não seria essa. Já no segundo item trocar mas por mais é passível de recursos e anulação.
  • Na 6 Ed. do Pressman, está na página 316.

  • Livro  Engenharia de Software - Uma Abordagem Profissional - 7º Edição - Roger S. Pressman
    Capitulo 18 Testando Aplicativos Convencionais

    Operabilidade: Quanto melhor fucnionar, mais eficientemente pode ser testado.


ID
331561
Banca
FGV
Órgão
FIOCRUZ
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Um tipo de teste de sistemas de software é também chamado de “teste comportamental” e focaliza os requisitos funcionais do software, permitindo ao engenheiro de software derivar conjuntos de condições de entrada que vão exercitar plenamente todos os requisitos funcionais de um programa. Esse tipo de teste tende a ser aplicado durante os últimos estágios do teste e tenta encontrar erros em funções incorretas ou omitidas, de interfaces, de estrutura de dados ou de acesso à base de dados externa, de comportamento ou desempenho de iniciação e término. Além disso, é um tipo de teste que despreza, de propósito, a estrutura de controle, sendo a atenção focalizada no domínio da informação. Esse tipo é conhecido por teste:

Alternativas
Comentários
  • a) Os testes de caixa preta, diferentemente dos testes de caixa branca, são focados na parte funcional do sistema, sendo derivados dos requisitos
    especificados para o sistema, aonde não é necessário conhecimento sobre a estrutura interna do sistema (classes, métodos, entre outros). Deve-se ressaltar que esta não é uma alternativa em relação a Técnica de Caixa Branca, e sim um complemento. A abordagem baseado em erros é uma característica dos testes funcionais, que tem como objetivo definir valores de entrada divergentes dos especificados como esperados, e analisar os dados de saída.

    b) Os testes de caixa branca, também conhecidos como testes estruturais ou testes de vidro, são testes focados na estrutura interna do sistema e na análise de código, onde são testados os caminhos lógicos, conjuntos específicos de condições, loops( laços), e etc. Para os testes de caixa branca, são necessários conhecimentos em lógica de programação, e em alguns casos o conhecimento na linguagem de programação utilizada para o desenvolvimento do sistema também é requerido.

    c) O método de teste de fluxo de dados seleciona caminhos de teste de um programa de acordo com as localizações das definições e usos de variáveis no programa. São úteis para selecionar caminhos de teste de um programa que contenha instruções de laços e if aninhadas. Uma vez que as instruções de um programa relacionam-se entre si de acordo com as definições e usos de variáveis, a abordagem de teste de fluxo de dados é eficiente para a proteção contra erros. Porém, os problemas de medir a cobertura de teste e a seleção de caminhos de teste de fluxo de dados são mais complexos do que os correspondentes problemas para o teste de condição.

    d) Teste de caminho básico. Inicialmente é preciso estabelecer os possíveis caminhos de acordo com cada condição. Cada caminho é definido a partir de um conjunto de pré-condições determinadas por controles internos do sistema. Através de métricas e descrições sobre os fluxos de controle do programa, é possível determinar os casos de uso e os casos de teste.

    e) Nao conheço

    Fonte: www.ti24x7.com
  • A lógica composta está na parte de notação de grafo e fluxo. Avalia as condições (AND ou OR) nas decisões.

    Link interessante sobre o assunto:
    http://www.ic.uff.br/~bianca/engsoft2/index_arquivos/Aula9-EngSoft2.pdf

    F
    alou.
  • Um macete para facilitar:

    1) Teste Caixa Preta é conhecido como comportamental ou Teste funcional.

    2) Teste Caixa Branca é conhecido como teste de vidro.

  • Gabarito A

    Depois que o software é implantado, tende-se a fazer o teste de caixa-preta.

    Essas técnicas de Teste se dividem entre Funcional e Estrutural, sendo que o Teste Funcional, ou Teste de Caixa Preta (Black Box), é aquele que tem como alvo verificar se a implementação está de acordo com o que foi especificado. Já o Teste Estrutural, também chamado de Teste de Caixa Branca (White Box), busca garantir que o software desenvolvido esteja bem estruturado internamente, portanto, funcionando corretamente.

     

    "Retroceder Nunca Render-se Jamais !"
    Força e Fé !
    Fortuna Audaces Sequitur !
     

  • Teste de caixa-preta = pra enfiar na tua bcta;

    Teste de caixa-branca = pra enfiar na tua pelanca;

    Teste de caixa-azul, é pra enfiar no meio do c*


ID
334789
Banca
FCC
Órgão
TRT - 14ª Região (RO e AC)
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Garantir o funcionamento correto do software para atender as expectativas do cliente é o objetivo da homologação de sistemas. Nessa fase, que precede à implantação, os testes mais comuns são os testes:

Alternativas
Comentários
  • Nesse momento o usuário irá validar se a funcionalidade pedida foi implementada, verificará se o software é usável e também confirmará se a saída da funcionalidade está de acordo com o solicitado, aceitando ou não o software.
  • Questão subjetiva. Melhor eles copiarem e colarem, oque fazem normalmente, do que inventar questões com assertivas conflitantes