2-Teste de Software 2020

Engenharia de Software
Tema da Aula
Teste de Software
II – Técnicas de Teste
Engenharia
de Planejamento de Teste
Software
Por que Planejar o Teste?

• Teste pode consumir 50% a mais do que o esforço
estimado, em alguns projetos de teste.
• Aumentar a Qualidade do Teste e do Software
• Controlar os Gastos
Planejamento de Teste deve preocupar-se com:
• Inicialmente com a definição de Padrões e Normas
• Em segundo lugar com a definição do material que
será gerado pelo teste (testing work products)
Engenharia Ciclo de Vida do Software
de
Software e a Atividade de Teste
Ambiente de Ambiente de
Desenvolvimento Produção
Planejamento Análise Gerência e
Utilização
Projeto Codificação Controle
VV&T: Verificação, Validação e Teste de performance, recuperação

Testes (Unitário, Integração
e Aceitação) Simulação de Carga, Segurança etc.
Ambiente de Teste Ambiente de Simulação

Engenharia Técnicas de Teste
de
Software Tipos Básicos
1. Teste Funcional (ou Caixa Preta)
Este método testa o software a partir de sua funcionalidade
(comportamento), através de suas entradas e saídas (vê
o produto como uma caixa preta; não considera os
detalhes de implementação, ou seja: não observa o
código interno).
O Conjunto de casos de teste funcional deve exercitar todos

os requisitos do software e o testador deriva casos de
teste a partir da especificação do software.
de
Teste Funcional (ou Caixa Preta)
Os testes são realizados para demonstrar que:
1. As funções são operacionais e isentas de falhas;
2. As entradas são adequadas e as saídas são
corretamente produzidas;
3. A integridade das informações processadas é mantida.
Estes testes são realizados por desenvolvedores e

usuários.
de
2. Teste Estrutural (ou Caixa Branca)
Baseia-se num minucioso exame dos detalhes da
codificação (algoritmo).
Método, através do qual, o testador analisa o código gerado
(algoritmo), derivando casos de teste a partir da estrutura
interna do software.
de
Teste Estrutural (ou Caixa Branca)
O Conjunto de Casos de Teste estrutural provê medidas

para avaliar o grau de cobertura (% de cobertura; pelo
menos uma execução) de elementos da estrutura do
software (componentes, módulos, comandos, etc).
Engenharia
de Técnicas de Teste
Software
1- Caixa Preta ou Funcional:

2.1 Particionamento de Equivalência
2.2 Teste de Valor Limite
2.3 Teste de Comparação
...
2- Caixa Branca ou Estrutural:

1.1 Teste de Caminho Básico (estruturas de controle)
1.2 Teste de Condição (condições lógicas)
1.3 Teste de Fluxo de Dados
1.4 Teste de Laços
...
Engenharia
de Técnicas de Teste
Software
3. Teste de Validação (do tipo caixa preta):

3.1 Testes Alfa e Beta
3.2 Teste de Sistema
3.3 Teste de Recuperação
3.4 Teste de Segurança (e penetrabilidade)
3.5 Teste de Estresse
3.6 Teste de Desempenho
3.8 Teste de Cenários
...
4. Técnica de “Error Guessing” (adivinhar erros)
ou “Smelling Errors” (farejar erros).
Engenharia
de
Software
I - TESTE FUNCIONAL
(ou CAIXA PRETA)

Engenharia
de Teste Funcional (caixa preta)
Software
Abordagem macroscópica, baseada na especificação para

derivar os casos de teste.
✓ Foco nos Requisitos Funcionais
Objetivos:
• Verificar se uma entrada válida produz uma saída
correta (esperada);
• Validar os requisitos funcionais, através da interface do
software;
• Verificar a operacionalidade das funções.
Engenharia
Software
Útil para as seguintes categorias (classes) de defeitos:
• Funções incorretas ou ausentes

• Defeitos nas Interfaces (internas e externas)
• Erros de dados ou bases de dados externas
• Inicialização e terminação
• Sensibilidade do sistema a certos valores de entrada
• Volume e taxa de dados que o sistema suporta
Engenharia
Software
Técnicas Utilizadas:
• 1- Particionamento de Equivalência
• 2- Análise de Valores Limites
• 3- “Error Guessing”
• 4- Teste de Cenários (Roteiros)
Engenharia
Software
Questões que devem ser respondidas:

• Funções estão válidas?
• Quais classes de entradas caracterizarão bons casos
de teste?
• Sistema é sensível a certos valores de entrada?
• Qual o comportamento do sistema nos limites e
fronteiras das classes de entrada?
• Quais volumes e taxas de dados o sistema suporta?
• Qual efeito produzido pelo software com algumas
combinações específicas de dados
Engenharia Teste Funcional (caixa preta)
de
Software Exemplo de Casos de Teste
REQUISITOS:
• O programa TPTRIANG deverá receber três valores
quaisquer.
• Estes valores serão interpretados como os
comprimentos dos lados de um triângulo.
• O programa deverá apresentar uma mensagem
TPTRIANG
indicando se o triângulo é:
• ISÓSCELES (2 lados iguais) A B C
• ESCALENO (3 lados diferentes)

• EQUILÁTERO (3 lados iguais) TIPO DE TRIÂNGULO
de
CONDIÇÕES DE TESTE:
1. Isósceles
2. Permutação de isósceles
3. Escaleno
4. Permutação de escaleno
5. Equilátero
6. Um lado igual a zero
7. Permutação com lados iguais a zero
8. Um lado negativo
9. Permutação com valores negativos
10. Valores onde A + B = C
11. Permutação do item 10 TPTRIANG
12. Valores onde A + B < C
13. Permutação do item 12
14. Três valores iguais a ZERO A B C
15. Valores não numéricos
16. Dois valores
17. Valores com tamanhos máximos dos campos
18. Valores com tamanhos mínimos dos campos TIPO DE TRIÂNGULO
de
PLANILHA DE CASOS DE TESTE:
TESTE CONDIÇÃO A B C RESULTADO

01 1,2,18 2 2 1 ISÓSCELES
02 1,2,18 2 1 2 ISÓSCELES
... ... ... ... ... ...
09 6,7,18 1 0 1 ERRO
... ... ... ... ... ...
15 8,9 -1 2 3 ERRO
... ... ... ... ... ...
Engenharia Técnicas de Teste Funcional
de
Software 1- Particionamento de Equivalência
✓ Divide o domínio de entrada do programa em classes de
dados (Classes de Equivalência)
✓ Os casos de teste serão derivados a partir das Classes

de Equivalência definidas
• O valor representativo de uma Classe de
Equivalência é equivalente a outro(s) da mesma
classe
✓ O Particionamento de Equivalência busca definir um caso

de teste que descobre classes de erros, reduzindo o
número total de casos de testes que precisam ser
desenvolvidos
de
✓ Uma Classe de Equivalência representa um conjunto de

estados válidos ou inválidos para condições de entrada.
✓ Uma condição de entrada pode ser:

• Um valor específico
• Um intervalo de valores
• Um conjunto de valores relacionados
• Uma condição booleana
de
de
Exemplo: Condições
Código de área vazio ou três dígitos numéricos que
iniciem por “zero”
Prefixo três dígitos numéricos que não

iniciem por “zero”
Sufixo quatro dígitos numéricos
Senha seis dígitos alfanuméricos
Operação c=cheque, d=depósito, e=extrato

de
Exemplo: Caso de teste
Código de área
✓ Condição booleana (estar ou não presente)
✓ Conjunto de valores de 000 a 099
✓ Valor limite 100
Prefixo
✓ Vazio
✓ Valor < 100
Sufixo
✓ Vazio
de
Exemplo: Caso de teste
Senha
✓ Condição booleana (estar ou não presente)
✓ Conjunto de 6 caracteres alfanuméricos
✓ Presença de caracteres especiais ?
✓ Conjunto de 1 a 5 caracteres
✓ Conjunto vazio (espaços)
Comando
✓ Entrada de 1 caractere válido (c,d,e)
✓ Entrada de 1 caractere inválido
✓ Comandos especiais (ESC, F1 ...)
de
Software 2- Análise dos Valores de Fronteira
Grande número de erros tendem a ocorrer nas fronteiras de
uma região usada para definir limites (por exemplo um
valor que, para ser válido, deve estar entre 1 e 10).
Esta técnica complementa a técnica de Particionamento.
Execução: Testar os limites (próximo ao limite interno e

próximo ao limite externo) de cada classe de equivalência
não pontual (cujo domínio é dado por mais de um valor).
de
Software 2- Análise dos Valores de Fronteira
Teste de Valores de Fronteira:
Limite - a Limite + a
• Conjunto de Valores: Testar todos que possível

• Faixa de Valores: limite, limite + a e limite - a
• Estruturas de Dados (Ex: vetor com 100 posições)
Testar os valores armazenados nos índices que
representam os limites da estrutura
Engenharia
de
Técnicas de Teste Funcional
Software 3- Técnica de “Error Guessing”
Guess (suposição, conjetura,
estimativa)
Pessoas “farejadoras” (“smelling errors”) que, através da Intuição

e/ou Experiência, tem grande habilidade em compor Casos de
Teste.
1) Enumerar listas de situações tipicamente propensas a erros e
possíveis tipos de erros.
2) Escrever casos de teste baseados nessas listas
Engenharia
de
Software 4- Técnica de Cenários (Roteiros)
Criar cenários (roteiros) agrupando os Casos de Teste já
elaborados e usados, para reproduzir situações
(eventos) do mundo real.
Complementa as técnicas anteriores e revela-se muito útil
em teste de Integração e Aceitação e de Sistema.

Engenharia
de
Software 4- Técnica de Cenários (Roteiros)
Ex: Sistema Bancário (Casos de Teste já aplicados)
▪ CT #1: Abrir a Conta
▪ CT #2: Depósito
Casos de
▪ CT #3: Retirada teste já
▪ CT #4: Fechar a Conta aplicados
▪ CT #5: Saldo devedor Cenários
▪ CT1 + CT2 + CT3 (c/ valor maior que saldo) criados
▪ CT #6: Transferência entre contas com os casos
▪ CT1 + CT2 (conta 1) existentes
▪ CT1 + CT2 (conta 2)
▪ CT#7 (debitar na conta 1 e creditar na conta 2)
(O caso de teste #7 é novo: movimento entre contas)
Engenharia
de
Software
II - TESTE ESTRUTURAL
(ou CAIXA BRANCA)

Engenharia
de
Software Teste Estrutural (Caixa Branca)
Objetivo: Caracterizar que um determinado conjunto de
componentes elementares (comandos, ramos
condicionais, caminhos) foram exercitados (cobertos) por
um conjunto de casos de teste.
Útil para as seguintes categorias de defeitos:

• Expressões lógicas e afirmativas incorretas
• Erros tipográficos (trocar > por um <)
• Seleção incorreta de caminhos
• Em casos especiais ou raros (exceções)
Engenharia
de
Software Teste Estrutural (Caixa Branca)
✓ Exige instrumentação do programa fonte
✓ Técnica Mais Utilizada:

Teste do Caminho Básico (ou estruturas de controle).
Para isso deve-se traçar o Grafo de Fluxo de Controle
(GFC), que descreve o fluxo de controle lógico do
programa, usando notação própria (transformar um
programa em um GFC).
Engenharia
de Teste Estrutural (Caixa Branca)
Software
Grafo de Fluxo de Controle
GFC: É um Grafo Dirigido com um único nó de entrada e um
único nó de saída.
Para obtê-lo é preciso decompor um programa em blocos
de comandos, ligando-os através de arcos.
✓ Nós: Blocos de Comandos

✓ Arcos ou Ramos: Transferência de fluxo entre blocos
✓ Caminho: Sequência de nós n1,n2,n3,...,nm, desde que
haja um arco ligando ni a ni+1.
✓ Região: Áreas delimitadas por ramos e nós.
Engenharia
Software
O Grafo de Fluxo de Controle é criado pela transposição do
fluxo do programa (dispositivos lógicos) em estruturas
padrões (simplificação):
Engenharia
Software
Notação básica do GFC
If-Then-Else
if (condição) {1}
bloco 1 {2}
else
bloco 2; {3}
end-if {4}
Engenharia
Software
Do While
while (condição) {2}

bloco {3}
end-while {4}
Engenharia
Software
Do Until
do
bloco {2}
until (condição) {3}
próximo-comando {4}
Engenharia
de Técnicas de Teste Estrutural
Software
Teste de Caminho Básico
1. Fluxograma
Engenharia
Software
2. GFC equivalente ao Fluxograma.
Engenharia
Software
1. Fluxograma 2. GFC equivalente ao Fluxograma

Engenharia
Software
Critérios Estruturais Clássicos
Critérios Estruturais:
Consideram apenas as informações do fluxo de controle
do programa.
Critérios Estruturais Clássicos:

✓ Todos os Nós
✓ Todos os Arcos
✓ Todos os Caminhos (Teste Exaustivo)
✓ Todos os Caminhos Independentes
Engenharia
Software
Critério Estrutural: Todos os Nós
• Exige que os casos de teste exercitem todos os nós pelo
menos uma vez. Se todos os Nós forem Executados, todos
os comandos terão sido exercitados pelo menos uma vez.
Critério Estrutural: Todos os Arcos

• Exige que os casos de teste exercitem todos os arcos pelo
menos uma vez. Se todos os Arcos forem Executados,
todos os nós terão sido executados pelo menos uma vez.
Engenharia
Software
Critério Estrutural: Todos os Caminhos (Teste Exaustivo)
• Considere um programa de 100 linhas em linguagem C.
• Depois de algumas declarações básicas de dados, o
programa contém 2 ciclos aninhados, que executam de 1 a
20 vezes cada um, dependendo das condições
especificadas na entrada.
• Dentro do ciclo interior, quatro construções se-então-senão
são necessárias.
• Há aproximadamente 1014 caminhos possíveis que podem
ser executados nesse programa.
Engenharia
Software
Critério Estrutural: Todos os Caminhos (Teste Exaustivo)
• Considere-se um Processador de Teste Mágico para Testes
Completos (não existe).
• O processador pode desenvolver 1 caso de teste, executá-
lo e avaliar os resultados em um milissegundo.
• Trabalhando 24h por dia, 365 dias por ano, o processador
trabalharia 3.170 anos para testar o programa.
• Conclusão: na atualidade, Teste Exaustivo é impossível
para grandes sistemas de software.
Engenharia
Software
Todos os caminhos independentes:
• Baseado na Análise de Complexidade Ciclomática do
Código de Thomas McCabe (vide Métricas);
• Garante que todos os comandos (nós do GFC) e todos
os ramos (arcos do GFC) serão cobertos;
Caminho Independente é qualquer caminho do
programa que introduza pelo menos um novo conjunto
de instruções de processamento ou uma nova condição;
Nó Predicativo: Aquele que tem duas ou mais saídas
(condição).
Engenharia
Software
Nó Predicativo
Engenharia
Software
Todos os Caminhos Independentes
Caminhos Independentes:
Engenharia Técnicas de Teste Estrutural
de
Software
1-Todos os Caminhos Independentes
Exemplo de Caminhos
Independentes:
Grafo Derivado do Fluxograma
1. 1-11
2. 1-2-3-4-5-10-1-11
3. 1-2-3-6-8-9-10-1-11
4. 1-2-3-6-7-9-10-1-11
Todos incluem, pelo menos, 1 novo

arco
O Caminho 1-2-3-4-5-10-1-2-3-6-8-
9-10-1-11 não é independente
(é uma simples combinação
dos caminhos 2 e 3)
de
Software
Caminhos Independentes:
a) 1,2,3,4,6 1
b) 1,3,4,6
c) 1,2,3,4,5,4,6 2
Outro caminho possível é: 3

d) 1,3,4,5,4,6
Afinal, quantos caminhos existem?

4
Aplicar o conceito de “Conjunto Máximo”
aumenta a confiabilidade do conjunto
de casos de teste (suite de casos de 6
teste).
5
de
Software
O número de Caminhos Independentes pode ser calculado

usando-se o GFC desenhado manualmente ou calculado
automaticamente através de programa que calcula a
Métrica de complexidade Ciclomática de Thomas
McCabe.
A Complexidade Ciclomática V(G) nos oferece um limite

máximo para o número de caminhos independentes que
constitui o conjunto básico, portanto um limite máximo
para o número de testes que deve ser projetado e
executado para garantir a cobertura de todas as
instruções do programa.
de
Software
Métrica da Complexidade Ciclomática “V(G)” pode ser

calculada de três maneiras diferentes:
1. V(G) = ( No_de_Arcos - No-de_Nos ) + 2 ou
2. V(G) = No_de_Nós_Predicativos + 1 ou
3. V(G) = No_de_Regiões
de
Software
Ra1
Ra2 Ra11
1- V(G) = (Ramos – Nós) + 2
Ra3 Ra4 4 = (11 – 9) + 2
Ra6
Ra5 2. V(G) = Nós-Predic + 1
Ra10 4=3+1
Ra7 Ra8
Ra9 3. V(G) = No-Regiões

4=4
de
Software
1o:
1–9
2o:
1–2–8–7–1–9
3o:
1–2–3–5–6-7–1–9
4o:
1–2–3–4–6-7–1–9
Engenharia
de Projeto de Casos de Teste
Software
Teste Funcional ou Estrutural?
Eis a questão!
✓ Lembre-se do Paradoxo do Pesticida:

Todo método usado para prevenir erros/defeitos é ineficaz
para algum tipo de erro/defeito.
✓ São Técnicas complementares pois revelam erros de

categorias diferentes
Engenharia
de Atividades de VV&T
Software
Engenharia
de
Software
III - TESTE DE VALIDAÇÃO
(ou ACEITAÇÃO)
Engenharia Estratégias de Teste
de
Software
Teste de Validação (ou Aceitação)
✓ Encerrado o teste de integração, o software é um

“pacote” integrado.
✓ Teste de aceitação (validação) é bem sucedido quando o
software funciona de acordo com as expectativas
(razoáveis) do usuário (requisitos).
✓ Que são as expectativas do usuário?
• Definidas claramente nos Contratos de Requisitos
• Devem ser devidamente gerenciadas através de
técnicas de gerenciamento de requisitos (Gestão de
Configuração e Mudanças)
de
Software
Foco: Série de testes funcionais que demonstram a

conformidade com os requisitos do software, no
ambiente de produção.
✓ Assegurar o atendimento dos Requisitos Funcionais
(validar)
✓ Assegurar Documentação Correta e Inteligível
✓ Outras Características Importantes:
• Transportabilidade, Compatibilidade
• Recuperação de Erros, Manutenibilidade, etc...
de
Software
Possíveis Resultados do Teste de Aceitação:
✓ Aceitação pelo usuário
✓ Desvios ou Não-Conformidade
• Gera uma Lista de deficiências
• Negociar novos Prazos e, se for o caso, recursos ($$)

de
Software
Técnicas Utilizadas
Teste Alfa:
✓ Realizado no ambiente de desenvolvimento (“look over
the shoulders”)
✓ Desenvolvedor registra erros e problemas
✓ Ambiente controlado pelo testador
Teste Beta:
✓ Conduzido no ambiente do cliente/usuário
✓ Cliente relata os problemas (verdadeiros e frutos da
imaginação) ao desenvolvedor
de
Software
Outras Técnicas Utilizadas:
Aderência a padrões
✓ Check-list são definidos para validar:
• padrões de Interface entre sistemas
• Padrões de telas
• Padrões de relatórios
✓ Revisão gramatical (português) e de terminologia

utilizada (glossário da organização).
de
Software
Técnica de Revisão de Configuração:
✓ Também chamada de “Auditoria Geral”
✓ Assegurar que todos os elementos do software foram
desenvolvidos, catalogados e existe documentação
detalhada para dar suporte à manutenção
✓ Prática Comum nas Equipes de homologação (SQA)
Software Quality Assurance (SQA) =

Garantia da Qualidade de Software
Engenharia
de
Software
VI - TESTE DE SISTEMA
(ou TESTE FINAL ou
TESTE DE PLATAFORMA DE PRODUÇÃO)
de
Software Teste de Sistema
Foco: Verificar a relação entre vários elementos do sistema

(hardware, software, banco de dados, etc), depois de
validado e antes da implantação. Teste fora do escopo
exclusivo da Engenharia de Software
✓ Lembre-se: o Software é apenas um componente de

grandes sistemas computacionais (automação).
✓ Pode antecipar problemas que só aparecerão quando o
software estiver implantado em ambiente de produção
de
Recovery Testing (Teste de Recuperação)
Foco: Forçar o sistema a falhar, em relação à diversos

aspectos do sistema computacional e verificar a resposta
em termos de recuperação do sistema.
✓ Recuperação, Reinicialização
✓ Sistema Tolerante a Falhas

de
Security Testing (Teste de Segurança)

Foco: verificar todos aspectos ligados à segurança do
sistema.
✓ Níveis de usuário (privilégios)
✓ Invasão Externa (penetrabilidade).
Extremamente importante para produtos de Web como
Educação a Distância, E-commerce, Bancos, Governo, etc.
✓ Testador deve agir como “hacker” (burlar a segurança)

de
Security Testing (Teste de Segurança)
Desde que haja tempo e recursos, um bom teste

de segurança acabará por penetrar o sistema.
A tarefa do projetista é fazer com que o acesso
custe mais do que o valor da informação que
será obtida.
de
Stress Testing (Teste de Fadiga)

Foco: Verificar as respostas do sistema quando
submetido a anormalidades (em quantidade, frequência
e volume)
✓ Aumentar o número da taxa de interrupções
✓ Entradas em quantidade fora do normal (DDoS ATTACK
- Distributed Denial-of-Service ATTACK)
✓ Requerer uso máximo de memória (real e virtual)
✓ Manipular arquivos grandes e discos cheios
de
Performance Testing (Teste de Desempenho)

Foco: Verificar requisitos de performance em sistema de
tempo real (requisitos com restrições de performance)
✓ Pode ser conduzida conjuntamente com o teste de stress
✓ Requer instrumentação e manipulação de hardware e
software
✓ Importante em software de tempo real e software
embarcado.
de
Software Quando concluir os testes ?
O teste pode mostrar a presença, mas nunca a ausência

de erros no software. E. Dijkstra, 1969.
Como obter critérios para a conclusão de testes?

Resposta 1: Você jamais completará a atividade de teste.
A carga simplesmente se transfere do desenvolvedor
para o usuário pois toda vez que o software é executado
ele está sendo testado em relação a um novo conjunto de
dados.
Resposta 2: A atividade de teste só se esgotaria quando o

projeto estiver sem tempo (prazo) e dinheiro
(orçamento).
de
Software Quando concluir os testes ?
Critérios mais rigorosos para que, no mínimo, possamos

definir um mínimo aceitável de teste.
1) Modelos de confiabilidade
2) Medidas e métricas

2-Teste de Software 2020

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

2-Teste de Software 2020

Enviado por

Direitos autorais:

Formatos disponíveis

Engenharia de Software

Por que Planejar o Teste?

VV&T: Verificação, Validação e Teste de performance, recuperação

Ambiente de Teste Ambiente de Simulação

O Conjunto de casos de teste funcional deve exercitar todos

Estes testes são realizados por desenvolvedores e

O Conjunto de Casos de Teste estrutural provê medidas

1- Caixa Preta ou Funcional:

2- Caixa Branca ou Estrutural:

3. Teste de Validação (do tipo caixa preta):

(ou CAIXA PRETA)

Abordagem macroscópica, baseada na especificação para

Útil para as seguintes categorias (classes) de defeitos:

• Funções incorretas ou ausentes

Questões que devem ser respondidas:

• ESCALENO (3 lados diferentes)

TESTE CONDIÇÃO A B C RESULTADO

✓ Os casos de teste serão derivados a partir das Classes

✓ O Particionamento de Equivalência busca definir um caso

✓ Uma Classe de Equivalência representa um conjunto de

✓ Uma condição de entrada pode ser:

iniciem por “zero”

Prefixo três dígitos numéricos que não

Sufixo quatro dígitos numéricos

Senha seis dígitos alfanuméricos

Operação c=cheque, d=depósito, e=extrato

Esta técnica complementa a técnica de Particionamento.

Execução: Testar os limites (próximo ao limite interno e

Teste de Valores de Fronteira:

• Conjunto de Valores: Testar todos que possível

Pessoas “farejadoras” (“smelling errors”) que, através da Intuição

Criar cenários (roteiros) agrupando os Casos de Teste já

elaborados e usados, para reproduzir situações

(eventos) do mundo real.

Complementa as técnicas anteriores e revela-se muito útil

em teste de Integração e Aceitação e de Sistema.

(ou CAIXA BRANCA)

Útil para as seguintes categorias de defeitos:

✓ Técnica Mais Utilizada:

✓ Nós: Blocos de Comandos

while (condição) {2}

1. Fluxograma 2. GFC equivalente ao Fluxograma

Critérios Estruturais Clássicos:

Critério Estrutural: Todos os Arcos

Todos incluem, pelo menos, 1 novo

Outro caminho possível é: 3

Afinal, quantos caminhos existem?

O número de Caminhos Independentes pode ser calculado

A Complexidade Ciclomática V(G) nos oferece um limite

Métrica da Complexidade Ciclomática “V(G)” pode ser

1. V(G) = ( No_de_Arcos - No-de_Nos ) + 2 ou

Ra9 3. V(G) = No-Regiões

Teste Funcional ou Estrutural?

✓ Lembre-se do Paradoxo do Pesticida:

✓ São Técnicas complementares pois revelam erros de

III - TESTE DE VALIDAÇÃO

✓ Encerrado o teste de integração, o software é um

Foco: Série de testes funcionais que demonstram a

Possíveis Resultados do Teste de Aceitação:

✓ Aceitação pelo usuário

• Gera uma Lista de deficiências

• Negociar novos Prazos e, se for o caso, recursos ($$)

Outras Técnicas Utilizadas: