QUALIDADE E TESTE DE SOFTWARE - AULA 6

Prévia do material em texto

QUALIDADE E TESTE DE 
SOFTWARE
Aula 6
Prof. Daniel Silos – 1ª edição – 2020
E-mail: daniel.moraes@ibmr.br
Prof. Daniel Silos – daniel.moraes@ibmr.br 1
mailto:Daniel.Moraes@ibmr.br
6.TESTES DE SOFTWARE
 TESTE DE INTEGRAÇÃO
Prof. Daniel Silos – daniel.moraes@ibmr.br 2
6.TESTES DE SOFTWARE
 OBJETIVOS DA APRENDIZAGEM
1. Reconhecer os testes de integração
2. Aplicar testes de integração
Prof. Daniel Silos – daniel.moraes@ibmr.br 3
Estratégias...
Prof. Daniel Silos – daniel.moraes@ibmr.br 4
Engenharia de Sistemas
Teste de Sistema
Codificação
Teste de unidade
Projeto/Design
Teste de Integração
Modelagem / Requisitos
Teste de Validação
Teste de Integração
 Softwares Convencionais
 Incremental ou não incremental (“big bang”)
Qual a melhor?
Prof. Daniel Silos – daniel.moraes@ibmr.br 5
Exercício
O que são drivers e stubs 
(pseudocontroladores e 
pseudocontrolados)?
Prof. Daniel Silos – daniel.moraes@ibmr.br 6
Nota
Driver e stub representam despesas indiretas
no projeto de desenvolvimento de software,
pois são softwares que devem ser escritos e
que não serão fornecidos com o produto
final.
Prof. Daniel Silos – daniel.moraes@ibmr.br 7
Teste de Integração
Softwares Convencionais
Integração Incremental 
Descendente
Ascendente
Sanduiche
Prof. Daniel Silos – daniel.moraes@ibmr.br 8
Integração Descendente ou Top-down 
Prof. Daniel Silos – daniel.moraes@ibmr.br 9
- Primeiro-em-profundidade
M 1
M 3M 2 M 4
M 7M 6M 5
M 8
Integração Descendente ou Top-down 
Prof. Daniel Silos – daniel.moraes@ibmr.br 10
- Primeiro-em-largura
M 1
M 3M 2 M 4
M 7M 6M 5
M 8
Papel dos drivers e stubs
Prof. Daniel Silos – daniel.moraes@ibmr.br 11
O que utilizamos na integração 
descendente, pseudocontrolados ou 
pseudocontroladores?
Integração Ascendente 
(bottom-up)
Prof. Daniel Silos – daniel.moraes@ibmr.br 12
Integração sanduíche
Prof. Daniel Silos – daniel.moraes@ibmr.br 13
Como vocês imaginam que seja uma 
integração sanduíche?
Integração sanduíche
Prof. Daniel Silos – daniel.moraes@ibmr.br 14
Uma abordagem combinada que usa top-
down para os módulos de níveis superiores 
e botton-up para os níveis subordinados; 
Qual seria uma vantagem dessa 
abordagem?
Testes de Regressão
 São executados após a correção de algum defeito ou após a
adição de uma nova funcionalidade. Seu objetivo é garantir
que nenhum defeito foi acrescentado após sua modificação.
Prof. Daniel Silos – daniel.moraes@ibmr.br 15
Testes de Regressão
Os casos de testes de regressão podem ser de três tipos:
 Casos de teste que abrangem todas as funcionalidades do sistema.
 Casos de teste apenas para as funcionalidades que foram modificadas.
 Novos casos de teste para as funcionalidades que provavelmente foram
afetadas pela mudança (há ligação direta ou indireta com a parte
modificada.
Prof. Daniel Silos – daniel.moraes@ibmr.br 16
Testes de Regressão
 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 introduzam efeitos colaterais
indesejáveis.
 Ele pode ser conduzido manualmente ou usando alguma
ferramenta automatizada de captação/reexecução e que
iremos estudar posteriormente.
Prof. Daniel Silos – daniel.moraes@ibmr.br 17
Testes de Regressão
A utilização de ferramentas automatizadas 
permitirão captar casos de teste e resultados 
para reexecução e comparação. À medida que o 
teste de integração prossegue, o número de 
testes de regressão pode crescer 
significativamente.
Logo, a suíte de testes de integração deve ser 
projetada para incluir apenas testes que cuidam 
das principais funções do programa.
Prof. Daniel Silos – daniel.moraes@ibmr.br 18
Teste fumaça
Projetado como mecanismo de marca-passo para 
projetos de prazo crítico, permitindo que a equipe 
avalie seu projeto frequentemente. De uma forma 
geral, esta abordagem abrange as seguintes 
atividades:
1. Os componentes de software são integrados em 
uma “construção”. Esta construção inclui todos 
os dados, bibliotecas, módulos reusáveis e 
componentes que são necessários para 
implementar uma ou mais funções do produto.
Prof. Daniel Silos – daniel.moraes@ibmr.br 19
Teste fumaça
2. Uma série de testes é projetada para expor 
erros que impeçam a construção de 
desempenhar adequadamente a sua função. A 
finalidade deverá ser descobrir erros 
“bloqueadores” que tem a maior chance de 
atrasar o cronograma.
3. A construção é integrada com outras 
construções e o produto inteiro é testado 
diariamente. A abordagem pode ser 
descendente ou ascendente.
Prof. Daniel Silos – daniel.moraes@ibmr.br 20
Teste fumaça - Benefícios
 O risco de integração é minimizado já que 
incompatibilidades e outros erros de bloqueio são 
descobertos logo no início, evitando impactos no 
cronograma.
 A qualidade do produto final é aperfeiçoada, pois tanto 
erros funcionais quanto defeitos de projeto arquitetural 
podem ser descobertos.
 Diagnóstico e correção de erros são simplificados, pois o 
software que acabou de ser adicionado às construções é 
uma causa provável do erro recém-descoberto.
 O progresso é fácil de avaliar, pois como a cada dia que 
passa, o teste está mais integrado ao software, 
demonstrando como ele funciona.
Prof. Daniel Silos – daniel.moraes@ibmr.br 21
Considerações
Prof. Daniel Silos – daniel.moraes@ibmr.br 22
 Especificação dos requerimentos de uma forma 
quantificável deve ser realizada bem antes do 
início da atividade dos testes “práticos”. 
 Definição e explicitação de objetivos dos 
testes. 
 Compreensão dos diferentes usuários do 
software e planejamento de um perfil para 
cada categoria. 
 Desenvolvimento de um plano de testes que 
enfatiza um “ciclo de teste rápido”.
E na OO, como funciona a integração?
Prof. Daniel Silos – daniel.moraes@ibmr.br 23
 não há uma estrutura óbvia de controle hierárquico 
 as estratégias de integração ascendente e 
descendente perdem o significado 
 Há duas estratégias existentes para o contexto OO:
1. Teste baseado no caminho de execução: 
Integra o conjunto de classes necessárias para 
responder a uma entrada ou evento do sistema.
2. Teste baseado no uso: Começa a construção do 
sistema testando as classes que usam poucas 
(ou nenhuma) classes servidoras.
Teste de Validação
Prof. Daniel Silos – daniel.moraes@ibmr.br 24
Começa quando termina o teste de integração
Não há distinção entre paradigmas de 
programação.
É focado nas ações visíveis ao usuário e saída 
do sistema reconhecíveis pelo usuário, o foco 
está no nível de requisitos.
Critérios do teste de validação
Prof. Daniel Silos – daniel.moraes@ibmr.br 25
A validação de software é conseguida através 
de uma série de testes que demonstram 
conformidade com os requisitos. 
Desta forma o plano de teste descreve as 
classes de testes a serem conduzidas e um 
procedimento de teste define casos de teste 
específicos destinados a:
Critérios do teste de validação
Prof. Daniel Silos – daniel.moraes@ibmr.br 26
garantir que todos os requisitos funcionais 
sejam satisfeitos; 
todas as características comportamentais 
sejam obtidas;
Todo o conteúdo seja preciso e adequadamente 
apresentado;
todos os requisitos de desempenho sejam 
atendidos;
a documentação esteja correta.
Critérios do teste de validação
Prof. Daniel Silos – daniel.moraes@ibmr.br 27
Após cada caso de teste de validação ter sido 
conduzido, existe uma entre duas possibilidades: 
A característica de função ou desempenho está 
de acordo com a especificação e é aceita;
Descobre-se um desvio da especificação e é 
criada uma lista de deficiência;
Testes alfa e beta
Prof. Daniel Silos – daniel.moraes@ibmr.br 28
É muito difícil para um desenvolvedor prever 
como cliente usará realmente o programa. As 
instruções podem ser mal interpretadas, 
combinações estranhas de dados, saída que 
parecia clara pode não ser compreensível para 
umusuário e etc.
Se o software é desenvolvido para ser usado 
por vários clientes, não é pratico realizar 
testes formais de aceitação com cada um. A 
maioria dos construtores usa os processos 
chamados de testes alfa e beta.
Testes alfa e beta
Prof. Daniel Silos – daniel.moraes@ibmr.br 29
 Teste Alfa
 Este teste é conduzido na instalação do desenvolvedor por um
grupo representativo de usuários finais.
 O software é utilizado em um cenário natural e realizado em
conjunto desenvolvedores e usuários, registrando os erros e
os problemas de uso.
 Este tipo de teste normalmente é conduzido em um ambiente
controlado.
Testes alfa e beta
Prof. Daniel Silos – daniel.moraes@ibmr.br 30
 Teste Beta
 É conduzido nas instalações de um ou mais usuários finais e
neste tipo de teste o desenvolvedor não estará presente.
 O cliente registra todos os problemas encontrados durante o
teste e vai relatando para o desenvolvedor em intervalos
regulares.
 Com o resultado deste teste, os desenvolvedores fazem as
modificações necessárias e preparam a liberação do software
para todos os clientes.
Testes de Sistema
Prof. Daniel Silos – daniel.moraes@ibmr.br 31
 Realizado pelo time ou equipe independente de
software em projetos grandes e complexos – ITG
(Independent Test Group).
 Lembrem-se de que este time/equipe faz parte da
SQA (Garantia de Qualidade de Software).
 Sua presença é importante para garantir que o fator
“psicológico” não atrapalhe.
Testes de Sistema
Prof. Daniel Silos – daniel.moraes@ibmr.br 32
 Existem várias responsabilidades e papéis dentro da equipe:
Líder do projeto
de testes
Responsável pela liderança de um projeto de teste,
geralmente relacionado a um sistema em desenvolvi-
mento, seja um projeto novo ou manutenção.
Arquiteto Responsável pela montagem da infraestrutura de teste,
monta o ambiente de teste, escolhe as ferramentas de
teste e capacita a equipe para executar seu trabalho
neste ambiente.
Analista
do teste
Responsável pela modelagem e elaboração dos casos
de teste e pelos scripts de teste. Em alguns casos, os
scripts podem ser elaborados pelos testadores.
Testador Responsável pela execução dos casos de teste e
scripts.
Testes de Sistema
Prof. Daniel Silos – daniel.moraes@ibmr.br 33
Erros sobre Testes de Software
1. De modo algum o desenvolvedor deve testar.
2. O software deve ser “jogado” aos “estranhos” do
ITG.
3. O ITG se envolverá com o projeto somente
quando o teste começar.
Testes de Sistema
Prof. Daniel Silos – daniel.moraes@ibmr.br 34
Os testes podem ser baseados em:
Especificação de riscos e/ou de requisitos,
Processos de negócios,
Casos de uso.
Testes de Sistema
Prof. Daniel Silos – daniel.moraes@ibmr.br 35
✓Teste de recuperação;
✓Teste de segurança;
✓Teste de esforço;
✓Teste de desempenho;
✓Teste de disponibilização (configuração).
Tipos de Manutenção
Prof. Daniel Silos – daniel.moraes@ibmr.br 36
 Diferentes causas geram manutenções em um software
em produção, e podem ser classificadas em:
➢ Manutenção Corretiva;
➢ Manutenção Adaptativa;
➢ Manutenção Perfectiva;
➢ Manutenção Preventiva.
Técnicas de Testes de Software
Prof. Daniel Silos – daniel.moraes@ibmr.br 37
Caixa Branca – Foco no código-fonte.
Caixa Preta – Foco nos requisitos (funcionais e
não funcionais).
Caixa Branca
Prof. Daniel Silos – daniel.moraes@ibmr.br 38
Teste de Condição
Teste de Ciclo
Teste de Fluxo de Dados
Teste de Caminho Básico
Teste do caminho básico
Prof. Daniel Silos – daniel.moraes@ibmr.br 39
 Técnica de teste de caixa branca inicialmente
proposta por Tom McCabe.
Permite ao projetista do caso de teste derivar uma medida
da complexidade lógica de um projeto procedimental e usá-
la para definir um conjunto básico de caminhos de
execução;
A Complexidade Ciclomática é uma métrica que
proporciona uma medida quantitativa da complexidade
lógica de um programa.
Teste do caminho básico
Prof. Daniel Silos – daniel.moraes@ibmr.br 40
 Os casos de teste projetados para exercitarem este conjunto básico têm
garantia de executar cada instrução do programa pelo menos uma vez
durante a atividade de teste.
 Os seguintes passos devem ser aplicados:
1. Usando o projeto ou o código como base, desenhar o grafo de fluxo
correspondente;
2. Determinar a complexidade ciclomática do diagrama de fluxo resultante.
3. Determinar um conjunto base de caminhos linearmente independentes.
4. Preparar casos de teste que vão forçar a execução de cada caminho do
conjunto base.
Teste do caminho básico
Prof. Daniel Silos – daniel.moraes@ibmr.br 41
9
Exemplo: Segmento de programa fonte e seu correspondente grafo de
fluxo.
procedure:sort
1: do while records remain
read record;
2: if record field1 = 0
3: then process record;
store in buffer;
increment counter;
4: else if record field2 = 0
5: then reset counter;
6: else process record;
store in file;
7: endif
endif
8: enddo
9: end
1
2
4
6 5
7
3
8
Teste do caminho básico
Prof. Daniel Silos – daniel.moraes@ibmr.br 42
9
1
2
4
6 5
7
3
8
Caminho 1: 1-9
Caminho 2: 1-2-3-8-1 ...
Caminho 3: 1-2-4-5-7-8-1 ...
Caminho 4: 1-2-4-6-7-8-1 ... 
R3
R2
R1
R4
Teste do caminho básico
Prof. Daniel Silos – daniel.moraes@ibmr.br 43
INÍCIO
. . .
PARA I = 1 ATÉ NUM_ACIDENTES FAÇA
LEIA(TIPO_ACIDENTADO[I], FATALIDADE[I], LOCAL_ACIDENTE[I]);
SE TIPO_ACIDENTADO == 'S' ENTÃO
CONT_AC_S = CONT_AC_S + 1;
SENÃO SE TIPO_ACIDENTADO == 'B' ENTÃO
CONT_AC_B = CONT_AC_B + 1;
SENÃO CONT_AC_P = CONT_AC_P + 1;
FIM_SE
FIM_SE
FIM_PARA
. . .
FIM
Teste do caminho básico
Prof. Daniel Silos – daniel.moraes@ibmr.br 44
INÍCIO
. . .
PARA I = 1 ATÉ NUM_ACIDENTES FAÇA
LEIA(TIPO_ACIDENTADO[I], FATALIDADE[I], LOCAL_ACIDENTE[I]);
SE TIPO_ACIDENTADO == 'S' ENTÃO
CONT_AC_S = CONT_AC_S + 1;
SENÃO SE TIPO_ACIDENTADO == 'B' ENTÃO
CONT_AC_B = CONT_AC_B + 1;
SENÃO CONT_AC_P = CONT_AC_P + 1;
FIM_SE
FIM_SE
FIM_PARA
. . .
FIM
1
2
3
4
5
6
7
8
Teste do caminho básico
Prof. Daniel Silos – daniel.moraes@ibmr.br 45
INÍCIO
. . .
PARA I = 1 ATÉ NUM_ACIDENTES FAÇA
LEIA(TIPO_ACIDENTADO[I], FATALIDADE[I], LOCAL_ACIDENTE[I]);
SE TIPO_ACIDENTADO == 'S' ENTÃO
CONT_AC_S = CONT_AC_S + 1;
SENÃO SE TIPO_ACIDENTADO == 'B' ENTÃO
CONT_AC_B = CONT_AC_B + 1;
SENÃO CONT_AC_P = CONT_AC_P + 1;
FIM_SE
FIM_SE
FIM_PARA
. . .
FIM
1
2
3
4
5
6
7
8
Teste do caminho básico
Prof. Daniel Silos – daniel.moraes@ibmr.br 46
Teste do caminho básico
Prof. Daniel Silos – daniel.moraes@ibmr.br 47
Caminho 1: 1-8
Caminho 2: 1-2-3-5,7-1 ...
Caminho 3: 1-2-3-6-7-1 ...
Caminho 4: 1-2-4-7-1 ... 
Teste do caminho básico
Prof. Daniel Silos – daniel.moraes@ibmr.br 48
Caminho 1: 1-8
Caminho 2: 1-2-3-5,7-1 ...
Caminho 3: 1-2-3-6-7-1 ...
Caminho 4: 1-2-4-7-1 ... 
INÍCIO
. . .
PARA I = 1 ATÉ NUM_ACIDENTES FAÇA
LEIA(TIPO_ACIDENTADO[I], FATALIDADE[I], LOCAL_ACIDENTE[I]);
SE TIPO_ACIDENTADO == 'S' ENTÃO
CONT_AC_S = CONT_AC_S + 1;
SENÃO SE TIPO_ACIDENTADO == 'B' ENTÃO
CONT_AC_B = CONT_AC_B + 1;
SENÃO CONT_AC_P = CONT_AC_P + 1;
FIM_SE
FIM_SE
FIM_PARA
. . .
FIM
1
2
3
4
5
6
7
8
Quais valores de entrada 
podemos utilizar para 
testar os caminhos 
acima?
Teste do caminho básico
Prof. Daniel Silos – daniel.moraes@ibmr.br 49
 Formas de encontrarmos o número de caminhos básicos (ou independentes):
 Número de Regiões (já visto)
 Fórmulas:
1 - V(G) = E – N + 2 OU V(G) = P+1
Sabendo-se que:
V(G) – Complexidade Ciclomática
E – Número de arestas (edges)
N – Número de nós
P – Número de nós predicados
Teste do caminho básico
Prof. Daniel Silos – daniel.moraes@ibmr.br 50
Aplicando-se a Fórmula 1:
V(G) = E – N + 2
V(G) = 10 – 8 + 2 = 4.
Teste do caminho básico
Prof. Daniel Silos – daniel.moraes@ibmr.br 51
Aplicando-se a Fórmula 2:
V(G) = P + 1
V(G) = 3 + 1 = 4
Prof. Daniel Silos – daniel.moraes@ibmr.br 52
Para próxima aula
LER:
• PRESSMAN, Roger. Engenharia de Software: Umaabordagem Profissional. 8a edição. Capítulos 23 e 24. 
Bookman. 2016.
Prof. Daniel Silos – daniel.moraes@ibmr.br 53
Referências
SOMMERVILLE, I. Engenharia de Software. 9a 
edição. Capítulo 8. Pearson Addison Wesley. 
2011. 
PRESSMAN, Roger. Engenharia de Software: uma 
abordagem profissional. 8a edição. Capítulo 22. 
Bookman. 2016.