UNIVERSIDADE CATÓLICA DE MOÇAMBIQUE

Faculdade de Económica e Gestão

Testagem e Validação de Software

Atividades/Exercícios

Licenciatura em Tecnologias de Informação – Laboral 4 ano

De:

VALDIMIRO ABOO

Docente:

Dr. EDSON CARDOSO

BEIRA

MAIO DE 2021
1. Os processos de V&V tem a finalidade de verificar se o software em desenvolvimento
satisfaz a sua especificação e oferece as funcionalidades esperadas pelos stakeholders.

2. A Verificação refere-se ao conjunto de tarefas que garantem que o sistema em

desenvolvimento implementa corretamente uma função especifica, enquanto que a
Validação de software refere-se a um conjunto de tarefas que asseguram que o
software foi criado e pode ser rastreado segundo requisitos do cliente, ou seja, como
todas as outras etapas de teste, a validação tenta descobrir erros, mas o foco está no
nível de requisitos, em coisas que ficarão imediatamente aparentes para o usuário
final.

A Validação é particularmente difícil pois ele vai além de uma simples verificação de
conformidade com especificação, pois tenta demostrar que o software faz o cliente ou
stakeholders espetam que ele faça. Esta especificação nem sempre reflete os desejos
ou necessidades dos stakeholders ou clientes, causando assim muitos problemas.

3. Nós nunca podemos estar 100% certos de que um sistema de software seja livre de
defeitos ou tolerante a defeitos. Defeitos não detetados podem ficar adormecidos por
um longo tempo e falhas de software podem ocorrer após vários anos de
funcionamento confiável.

4. O objetivo de inspeções de software é melhorar a qualidade de artefactos de software

através de sua análise, detetando e removendo defeitos antes que o artefacto seja
passado para a próxima fase do processo de desenvolvimento de software, com foco
no código fonte.

5. Porque 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, é improvável descobrir erros de interações,
isto é, as inspeções não são boas para descobrir defeitos que surgem devido a

2
 interações inesperadas entre diferentes partes de um programa, problemas de timing
ou com o desempenho do sistema

6. As inspeções não podem substituir os testes de software, pois como o seu foco é o
código fonte, as inspeções não são boas para descobrir defeitos que surgem devido a
interações inesperadas entre diferentes partes de um programa, problemas de timing
ou com o desempenho do sistema. Além disso, pode ser difícil e caro montar uma
equipe de inspeção, especialmente em pequenas empresas ou grupos de
desenvolvimento, já que todos os membros da equipe também podem ser
desenvolvedores de software.

7.

 Se o usuário inserir dados em formato de string quando o computador estiver

esperando um número inteiro, ocorrerá um erro de execução;
 Erro causado pela divisão por zero;
 Erro causado pela atribuição / recuperação de valor de uma matriz usando um índice
que é maior que o tamanho da matriz
 Referenciando um elemento fora do intervalo de matriz;
 Erro de logica em estrutura de repetição, causando um loop infinito;

8.

 Variável usada antes da inicialização;

 Variável declarada, mas nunca usada;
 Variáveis não declaradas;
 Possivelmente violação de limite de array
 Função e procedimento desnecessários ou não chamados;
 Número de parâmetros incompatível

3
9. Teste de Unidade, identifica erros de lógica e implementação em pequenas unidades do
projeto de software, ajudando assim na codificação.

Teste de Integração, identifica erros na interação entre pequenas unidades do projeto de

software.

Teste de Regressão, consiste na reexecução do mesmo conjunto de testes que já foram

executadas para assegurar que não tem defeitos colaterais nas alterações feitas.

Teste de Sistema, identifica erros de funções e características de desempenho.

Teste de Caixa Branca, foca-se em testes na parte interna do software, isto é, o código fonte.
Ex: fluxo de condições.

Teste de Caixa Preta, não se usa nenhum detalhe interno na sua execução, testa
comportamento e foca na especificação. Ex: Input e Output.

10. Teste de Caixa Branca, foca-se em testes na parte interna do software, isto é, o
código fonte. Ex: fluxo de condições.
Teste de Caixa Preta, não se usa nenhum detalhe interno na sua execução, testa
comportamento e foca na especificação. Ex: Input e Output.

11. O desenvolvimento de software cleanroom é uma variação de modelo de métodos

formais, que possibilita especificar, desenvolver e verificar um sistema baseado em
computador através da aplicação de uma notação matemática rigorosa.

Vantagens:

 Oferecem um mecanismo que elimina muitos dos problemas difíceis de ser superados
com o uso de outros paradigmas de engenharia de software;

4
  Ambiguidade, incompletude e inconsistência podem ser descobertas e corrigidas mais
facilmente, devido à aplicação de análise matemática;
 Possibilitam que se descubra e se corrijam erros que, de outra forma, poderiam passar
despercebidos;

Desvantagens:

 Consome muito tempo e dinheiro;

 Necessário treinamento extensivo;
 É difícil usar os modelos como um meio de comunicação com clientes tecnicamente
despreparados;

12.

1. Segurança
a. Resultados de ataques simulados de phishing;

b. Tempo médio para se recuperar;

c. Teste de penetração
2. d. Número de ataques

3. Facilidade de compreensão

a. o índice Fog;
b. o comprimento médio dos identificadores;
c. Árvore de profundidade de herança
d. Número de frames de ajuda.

4. Portabilidade
a. Percentual de declarações dependentes do sistema-alvo;

5
 b. Número de sistemas-alvo.

5. Testabilidade
a. Número de falhas expostas durante os testes;
b. A probabilidade de um pedaço de software falhar na próxima execução dos testes
assumindo que uma entrada do software inclui uma falha.

6. Facilidade
a. Tempo de treinamento;
b. Número de frames de ajuda.

7. Confiabilidade
a. Probabilidade de falha sob demanda
b. Tempo médio para falha;
c. Probabilidade de indisponibilidade;
d. Taxa de ocorrência de falhas;
e. Disponibilidade.

8. Facilidade de adaptação

9. Facilidade de reuso
a. Métodos ponderados por classe

10. Capacidade de recuperação

a. Tempo médio para se recuperar;

11. Modularidade

6
a. facilidade em compreender os módulos de forma isolada;
b. desenvolvimento em paralelo;
c. possibilidade de manter os módulos de forma independente.

12. Eficiência
a. velocidade da CPU, quantidade de memória cache e memória RAM;
b. Desempenho de disco rígido, volume de tráfego de rede;
c.  tempos apropriados de resposta;
d. conformidade com padrões, convenções, regras de eficiência.

13. Complexidade
a. Profundidade de aninhamento condicional
b. Métodos ponderados por classe
c. Fan-in/Fan-out
d. número de atributos e operações associadas com as classes de objeto
e. complexidade ciclomática;
f. manutenibilidade.

14. Facilidade de aprendizado

a. Tempo de treinamento;
b. Número de frames de ajuda.