Logo Passei Direto
Buscar

Desenvolvimento de Software

Exatas
Testes de integração são feitos para que todas as funcionalidades já testadas considerem agora requisições de HTTP, servidores, SGBDs, APIs externas, gerações de arquivos, envio de mensagens e outras ações que façam parte do conjunto de funcionalidades num contexto real. Pensando em testes de integração, é correto afirmar que: A Testes de integração devem ser totalmente automatizados. B Testes de integração são apenas manuais. C Testes de integração podem ser feitos de forma automatizada e/ou manual. D Ferramentas de automação de testes de integração são apenas open-source. E Ferramentas de automação de testes de integração são apenas proprietárias (comerciais).
User badge image
Mandrake Fake

há 2 anos

User badge image
Mandrake Fake

há 2 anos

Questões sobre Qualidade de Software
5 pág.

Questões sobre Qualidade de Software

Respostas

User badge image

Ed Verified user icon

ano passado

Vamos analisar as alternativas sobre testes de integração: A) Testes de integração devem ser totalmente automatizados. - Embora a automação seja desejável, não é uma regra que todos os testes de integração devem ser automatizados. Existem situações em que testes manuais são mais apropriados. B) Testes de integração são apenas manuais. - Isso não é verdade, pois os testes de integração podem ser realizados tanto de forma manual quanto automatizada. C) Testes de integração podem ser feitos de forma automatizada e/ou manual. - Esta afirmação é correta, pois os testes de integração podem ser realizados de ambas as formas, dependendo das necessidades do projeto. D) Ferramentas de automação de testes de integração são apenas open-source. - Isso não é verdade, pois existem ferramentas de automação tanto open-source quanto proprietárias. E) Ferramentas de automação de testes de integração são apenas proprietárias (comerciais). - Assim como a alternativa D, isso também não é verdade, pois existem ferramentas open-source disponíveis. Portanto, a alternativa correta é: C) Testes de integração podem ser feitos de forma automatizada e/ou manual.

Essa resposta te ajudou?

0
Dislike0

Ainda não achou a resposta?

  • Integrado com os principais modelos de IA do mercado
  • Respostas em segundos
  • IA treinada para estudantes brasileiros.
PasseIA logoEvolua sua forma de estudar

Cadastre-se ou realize login

User badge image

Ed Verified user icon

há 2 anos

Analisando as opções apresentadas: A) Testes de integração devem ser totalmente automatizados - Embora a automação seja altamente recomendada para testes de integração devido à complexidade e variedade de cenários a serem cobertos, não é uma regra absoluta que eles devem ser totalmente automatizados. A combinação de testes automatizados e manuais pode ser benéfica em alguns casos. B) Testes de integração são apenas manuais - Esta afirmação está incorreta, pois os testes de integração podem e devem ser automatizados sempre que possível para garantir eficiência e cobertura adequada. C) Testes de integração podem ser feitos de forma automatizada e/ou manual - Esta opção está correta, pois os testes de integração podem ser realizados tanto de forma automatizada quanto manual, dependendo do contexto e das necessidades do projeto. D) Ferramentas de automação de testes de integração são apenas open-source - Esta afirmação está incorreta, pois existem tanto ferramentas de automação de testes de integração open-source quanto comerciais disponíveis no mercado. E) Ferramentas de automação de testes de integração são apenas proprietárias (comerciais) - Assim como na opção anterior, esta afirmação está incorreta, pois existem opções de ferramentas de automação de testes de integração tanto open-source quanto comerciais. Portanto, a opção correta é: C) Testes de integração podem ser feitos de forma automatizada e/ou manual.

Essa resposta te ajudou?

0
Dislike0

Ainda com dúvidas?

Envie uma pergunta e tenha sua dúvida de estudo respondida!

Essa pergunta também está no material:

Questões sobre Qualidade de Software
5 pág.

Questões sobre Qualidade de Software

Mais perguntas desse material

A norma ISO/IEC 15504 surgiu em 1991 e trazia consigo o pensamento da normatização de conceitos de facilitar as definições de características dos processos. Na sequência, em 1993, surgiu um projeto chamado SPICE (Software Process Improvement and Capability dEtermination) considerando três aspectos: auxiliar o projeto de norma 15504, inclusão de testes de campo e coleta de dados para consolidação da nova norma. Como outras normas e padrões, o seu objetivo é focado na melhoria de processos. Utiliza-se da análise de resultados como pontos fortes e fracos, bem como sobre o gerenciamento de riscos.
SPICE é dividida em etapas, sendo assim, a seguir temos a definição da parte 5:
A Estabelece os requisitos mínimos para realização da avaliação com boa granularidade para o processo. Nesta fase há classificação dos dados, implantação de responsabilidades e o desenvolvimento de modelos para acompanhamento dos processos.
B Traz uma introdução sobre os conceitos e avaliação dos processos, com destaque a um glossário que define os principais termos avaliativos do processo.
C Estabelece um exemplo de PRM (Process Assessment Model), o qual resume num modelo de referência de processos o ciclo de vida dos processos estabelecidos pela norma.
D Insere uma perspectiva para especificação dos processos, identificando pontos fortes, fracos e riscos.
E Fornece recomendações para avaliação dos requisitos.

Todas as metodologias ágeis têm em seu cerne a ideia de desenvolvimento de software com base sólida na qualidade de software. O BDD (Behavior Driven Development) é uma técnica ágil alinhada à colaboração do time de desenvolvimento com times de qualidade e trabalham fortemente na verificação e validação. Dentre as práticas do BDD, temos o envolvimento das partes interessadas, a descrição do comportamento da aplicação ou de uma unidade de código, a automação de testes para obtenção de feedback rápido, testes de regressão, a escrita de comportamentos com Should (deve) e o uso de simuladores de teste (mocks, fakes, spies) para colaboração entre módulos não escritos ainda.
Mesmo que controverso, há quem diga que o BDD é uma extensão de qual técnica ágil?
A FDD
B TDD
C Kanban
D Scrum
E DSDM

A ISO 12207 é uma norma que certifica sistemas de gestão de qualidade. Esta norma especifica fatores relacionados aos requisitos dentro das atividades de desenvolvimento de software.
Em muitos momentos tal norma pode ser utilizada em conjunto com a ISO citada a seguir:
A ISO/IEC 9000.
B ISO/IEC 12207.
C CMMI.
D MPS.br
E ISO/IEC 15504.

As medidas de testes mais importantes encontram-se na cobertura e na qualidade. A de cobertura associa a abrangência dos testes e a qualidade, a confiabilidade, estabilidade e o desempenho dos objetivos dos testes. Uma avaliação da cobertura fornece uma medida que avalia a conclusão dos testes e a avaliação dos defeitos indica qual a qualidade do software. Quando falamos em cobertura, temos dois tipos: a cobertura do código (code coverage) e a cobertura de testes (test coverage).
A cobertura de código tem por objetivo:
A Encontrar código não testado, e este tipo de atividade não é utilizada para metrificar a qualidade do software.
B Repassar código testado, atividade que é utilizada para metrificar a qualidade de software. Exploração de caminhos felizes, infelizes e alternativos, indicando código inútil, desnecessário e mal escrito. Previne defeitos nos estágios iniciais do ciclo de vida do software.
C Encontrar código não testado, atividade que é utilizada para bugar a qualidade de software. Exploração de caminhos felizes, indicando código inútil, desnecessário e mal escrito. Previne defeitos nos estágios finais do ciclo de vida do software.
D Encontrar código não testado, atividade que é utilizada para metrificar a qualidade de software. Exploração de unicamente caminhos alternativos, indicando código inútil, desnecessário e mal escrito. Previne defeitos nos estágios finais do ciclo de vida do software.
E Repassar código testado, atividade que é utilizada para metrificar a qualidade de software. Exploração de unicamente caminhos alternativos, indicando apenas código e mal escrito. Previne defeitos nos estágios finais do ciclo de vida do software.

Controlar a qualidade de software tem por objetivo principal a retenção de qualquer produto e ou versão/release que possa criar problemas para o cliente quando liberado. Além disso, o controle de qualidade garante na minimização do custo da qualidade. As atividades relacionadas ao controle da qualidade visam atender ao que?
A As causas dos erros, a detecção e correção dos erros que possam ocorrer o mais cedo possível.
B As causas dos erros para incluí-los no relatório de qualidade.
C As causas dos erros, porém a detecção dos mesmos é feita somente no processo de desenvolvimento.
D As causas dos erros a qualquer momento do processo de desenvolvimento.
E Corrigir os erros ao término da implantação das métricas de qualidade.

A avaliação da qualidade de software segundo a ISO/IEC 9126 tem por título geral “Engenharia de software - qualidade do produto”. Esta norma é alicerçada em quatro importantes pontos.
Os quatro pilares da ISO/IEC 9126 são:
A Modelo de software, modelo de qualidade e modelo de testes.
B Modelo de qualidade e métricas de produto.
C Métricas de processos e métricas de produto de software.
D Modelo de qualidade de software e Métricas de acompanhamento de processo de software.
E Modelo de qualidade, métricas externas, métricas internas e métricas de qualidade em uso.

As métricas são elementos intrínsecos à qualidade de software, podendo ser algo em relação à documentação ou meta dentro do processo de desenvolvimento de software. Estas métricas abordam situações tais como: linha de código, falhas e erros, por exemplo. Para facilitar nossa compreensão sobre as métricas, elas podem ser divididas em relação ao tempo, aos recursos e às ocorrências.
As métricas em relação ao tempo estão relacionadas:
A A um determinado tempo que um processo leva para ser concluído.
B Aos recursos que são utilizados para que um determinado processo seja executado.
C A um determinado evento como erro, defeito, inspeção de código, número de mudanças nos requisitos e número médio de defeito por linhas de códigos alteradas.
D Ao tempo e recurso de um determinado processo.
E Ao tempo e evento sobre um determinado processo.

A avaliação da qualidade de software segundo a ISO/IEC 9126 tem por título geral “Engenharia de software - qualidade do produto”. Esta norma é constituída por 6 subdivisões: Funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.
Dentro da Usabilidade encontramos as seguintes características:
A Compreensibilidade, apreensibilidade e operacionalidade.
B Maturidade, apreensibilidade e operacionalidade.
C Compreensibilidade, processos e qualidade.
D Maturidade, operacionalidade e processos.
E Compreensibilidade, usabilidade e metodologia.

Validação e Verificação estão relacionadas a testes de software. Há uma grande confusão entre os dois termos, pois os mesmos nos soam como sinônimos. Mas eles são completamente diferentes quando falamos de qualidade de software. Então, qual a diferença entre validação e verificação? * A ». A diferença entre validação e verificação é quase inexistente. De fato ambas dizem respeito ao processo de qualidade após o desenvolvimento de software. B- A verificação traz consigo tarefas que garantem a qualidade do software durante o processo de desenvolvimento (testes, unitários, integração de sistemas), enquanto que a validação é a fase na qual testamos se desenvolvemos o software correto. C- A validação é um processo que é feito durante o processo de desenvolvimento de software e a verificação é feita após a entrega do software. D- A fase de verificação é menos importante que a fase da validação, a qual é feita após o processo de desenvolvimento. E- A fase de validação corresponde apenas ao momento dos requisitos do software, enquanto que a verificação corresponde somente ao momento da aceitação do software.

Mais conteúdos dessa disciplina