apostila (2)
57 pág.

apostila (2)


DisciplinaEx Metologia Cientifica39 materiais199 seguidores
Pré-visualização18 páginas
efeitos colaterais obtidos.
a) Testes oficiais
b) Testes de equivalência 
c) Testes Automatizados
d) Testes frequentes
e) Testes Manuais
5 \u2013 Podemos afirmar sobre testes de baixo nível:
a) São testes realizados no fim do projeto.
b) São testes de hardware, por isso de baixo nível.
c) São testes completos do sistema.
d) Atuam nos problemas complexos do programa.
e) Atuam na identificação de problemas em um pe-
queno segmento do código fonte.
\u2003
Capítulo 3
1 - Modelagem ágil pode ser definida como:
a) Mais uma ferramenta de desenvolvimento de 
projetos de TI.
b) Um framework para o cotidiano.
c) Um conceito de documentação e codificação de 
software.
d) Um método antigo que ganhou uma abordagem 
nova.
e) Uma técnica inovadora de desenvolvimento com 
inteligência artificial.
2 - Story-Writing Workshops são:
a) Reuniões periódicas realizadas com os membros 
da equipe.
b) Relatórios de procedimentos do Analista de tes-
tes para acompanhar o projeto.
c) Histórias registradas de dificuldades que a em-
presa teve nas últimas tentativas de implantar um 
software.
d) Histórias que determinam o caminho ideal a ser 
seguido na modelagem ágil. 
e) Parte do escopo do projeto disponível à equipe 
de desenvolvimento.
3 \u2013 A condição de \u201cpronto\u201d no Scrum com teste de 
software pode ser:
a) Codificação + Teste concluído
b) Codificação + Teste + Integração concluída
c) Codificação + Teste + Regressão concluída
d) Codificação + Teste + Integração + Regressão + 
Instalação concluída
e) Todas as anteriores
4 \u2013 Que tarefa não oferece apoio ao teste de software 
para atingir seu objetivo?
a) Participar das discussões de definição de arqui-
tetura.
b) Identificar os \u201cmelhores\u201d analistas de teste para 
o projeto em questão.
c) Desconsiderar restrições tecnológicas.
d) Identificar as necessidades do ambiente de teste.
e) Participar das definições de tecnologias utiliza-
das.
5 \u2013 Complete a sentença
Um sistema com cobertura de testes desde o início 
deve realizar o máximo possível de testes automatizados 
para que o trabalho manual e repetitivo não venha a ocor-
rer. Isso trará ganho de tempo na execução dos testes. 
Os testes em métodos ágeis devem seguir o conceito de 
pequenas interações para que a informação de como o 
sistema está sendo construído e os erros que são detec-
tados possam ser rapidamente identificados e corrigidos. 
Ao término de uma interação, todos os testes devem ter 
sido executados com êxito.
\u2003
Testes de Software
52
Capítulo 4
1 \u2013 São certificações ISTQB/ BSTQB, exceto:
a) CTAL - TTA
b) CTFL
c) CBTS
d) CTAL \u2013 TA
e) CTAL - TM
2 \u2013 Associe a pergunta com o atributo de qualidade 
segundo a norma ISO/IEC 9126:
Usabilidade - é fácil de usar?
Funcionalidade - satisfaz as necessidades?
Portabilidade - é fácil de ser utilizado em outro am-
biente?
Eficiência - é rápido e eficiente?
Manutenibilidade - é fácil de alterar e corrigir?
Confiabilidade - é imune a falhas e estável?
3 \u2013 O objetivo deste padrão é habilitar a medição e 
comparação dos testes realizados em componentes de 
software. Os usuários deste padrão se tornam aptos a 
melhorar diretamente a qualidade de seus testes de 
componente e a qualidade de seus produtos de softwa-
re.
a) ISO/IEC - 9126
b) IEEE 829
c) BS \u2013 7925-1
d) BS \u2013 7925-2
e) ALATS
4 \u2013 Complete a sentença
Algumas normas e padrões estão sendo amplamente 
utilizadas pelas comunidades de testes de software. Mas 
por que uma norma é importante? Uma norma consoli-
da ideias e boas práticas já empregadas pelo mercado e/
ou pela comunidade acadêmica. Geralmente define uma 
nomenclatura padrão para facilitar a comunicação entre 
profissionais que tratam do assunto técnico envolvido.
Outros Tipos de Testes de 
Software - Glossário
Existem diversos outros tipos de teste que são apre-
sentados neste anexo.
Teste aleatório: Técnica de teste caixa-preta onde os 
casos de teste são selecionados de acordo com um perfil 
operacional, normalmente usando um algoritmo de ge-
ração pseudo-aleatória. Esta técnica pode ser usada para 
testar atributos não funcionais como confiabilidade e per-
formance.
Teste alfa: Teste operacional, simulado ou real, execu-
tado por usuários/clientes em potencial ou por uma equi-
pe independente de teste (de fora da organização) nas 
instalações do desenvolvedor. O teste alfa normalmente 
é usado como teste de aceite interno para softwares de 
prateleira.
Teste back-to-back: Testes onde duas ou mais varian-
tes de um sistema são executadas com as mesmas en-
tradas. As saídas são comparadas e analisadas caso haja 
discrepância. 
Teste baseado em código: idem teste caixa-branca.
Teste baseado em projetos: Técnica de teste onde os 
casos de teste são projetados com base na arquitetura e/
ou projeto detalhado do sistema (por exemplo: testes de 
interface entre componentes ou sistemas)
Teste baseado em requisitos: Técnica de teste onde 
os casos de teste são definidos com base nos objetivos 
do teste e as condições de teste derivadas dos requisitos. 
Por exemplo, testes que exercitam funções específicas ou 
investigam atributos não funcionais como confiabilidade 
ou usabilidade.
Teste baseado em riscos: Testes orientados para ex-
plorar e fornecer informação a respeito dos riscos do pro-
duto. 
Testes de Software
53
Teste baseado na especificação: idem teste caixa-pre-
ta.
Teste baseado no processo do negócio: Técnica de tes-
te onde os casos de teste são projetados com base nas 
descrições e/ou conhecimento do processo do negócio.
Teste beta: Teste operacional realizado por usuários/
clientes em potencial, fora das instalações do desenvolve-
dor, para determinar se um sistema satisfaz ou não suas 
necessidades e se encaixa nos processos do negócio. O 
teste beta normalmente é usado como um teste de aceite 
externo para softwares de prateleira para obter feedback 
do mercado.
Teste big-bang: Um tipo de teste de integração onde 
os elementos do software ou hardware (ou ambos) são 
combinados todos de uma vez em um sistema, ao invés 
de serem combinados em etapas. 
Teste bottom-up: Um tipo de teste de integração in-
cremental onde os componentes do nível mais baixo são 
testados e integrados primeiro. Este processo é repetido 
até que o componente do nível mais alto na hierarquia es-
teja testado. Facilita os testes dos componentes de nível 
mais alto. 
Teste comparativo: (1) Um padrão com o qual as me-
didas ou comparações podem ser feitas. (2) Um teste que 
pode ser usado para comparar componentes ou sistemas 
entre si ou com um padrão como em (1). 
Teste completo: idem teste exaustivo.
Testes de aceitação: Tem como objetivo confirmar que 
o sistema funciona de acordo com a especificação. Cada 
história deve estar associada a um conjunto de testes de 
aceitação. Tem como objetivo deixar claro para todos qual 
a expectativa do dono do produto (Product owner) em re-
lação ao requisito e a história do usuário.
Teste de aceite: Teste formal das necessidades, exigên-
cias e processos de negócio do usuário conduzidos para 
determinar se um sistema satisfaz ou não os critérios de 
aceite e para permitir que o usuário, cliente ou outra en-
tidade autorizada determinem se aceitam ou não o siste-
ma. 
Teste de aceite do usuário: idem teste de aceite
Teste de aceite local: Teste de aceite executado por 
usuários/clientes nas suas instalações, para determinar se 
o sistema satisfaz ou não as suas necessidades e se en-
caixa nos processos de negócio. Normalmente inclui har-
dware e software.
Teste de acessibilidade: Teste para determinar qual o 
grau de facilidade com que usuários com necessidades es-
peciais conseguem usar o sistema em teste. 
Teste de algoritmos