PCS2408

Fundamentos de Engenharia de
So2ware

Aula 25

Escola Politécnica da Universidade de São Paulo 1

 Processos de So0ware

• é um conjunto de a8vidades e resultados associados que

produzem um produto de so2ware

– então, um processo de so2ware se dá pela estruturação de um

conjunto de a8vidades que resultam num produto de so2ware

– deve contribuir para redução de custos, aumento da qualidade e

melhora da produ8vidade
 Etapas de Processo de So0ware
Levantamento
de Requisitos
Análise
Projeto
Implementação
Teste
Especificação Implantação

• Um processo contém diversas a;vidades divididas em fases.

• o encadeamento específico dessas fases dá-se o nome de
Modelo Prescri8vos ou não Prescri8vos de Processo
 Modelos Prescri;vos

• seguem uma forma mais definida e sistemá8ca de se

construir so2ware.
• surgiram para estruturar a8vidades de um processo
• prescrevem um conjunto de elementos e como esses
elementos se inter-relacionam
• Tipos de Modelos Prescri8vos:
– Cascata
– Modelo Incremental
– Modelo Evolucionário
 Ciclo de Vida Clássico ou Cascata
Engenharia
de Sistemas
Análise
Projeto
Codificação
Testes
Implantanção
 Problemas

• Projetos reais raramente seguem o fluxo sequencial – ocorre

alguma iteração

• O cliente tem dificuldade de declarar todas as exigências – há

dificuldade em acomodar incertezas de início de projeto no
modelo em cascata

• Uma versão de programa só estará disponível em fase

adiantada do cronograma.
 Modelo Incremental

• baseia-se na entrega rápida de um conjunto funcional para o

usuário, de forma que esse conjunto possa ser efe8vamente
u8lizado pelo usuário – entrega parcial
– precisa-se conhecer os requisitos do produto completo, ou seja os
requisitos são razoavelmente bem definidos e compreendidos.
– entregas sucessivas são feitas, culminando no produto completo que
atende os requisitos iden8ficados e acordados – o processo se
desenvolve de forma incremental – cada incremento: nova
funcionalidade é adicionada
– processo incremental combina elementos de fluxos lineares e
paralelos
 Modelo Incremental

1º Incremento – parte essencial do protudo, ou seja requisitos básicos que devem

ser atendidos para que o so2ware entre em operação
1º incremento entregue: cliente usa e fornece feedback que são analisados para o
planejamento do 2º incremento e assim sucessivamente.
• o modelo de processo incremental entrega um produto operacional a cada
incremento, ou seja um produto pronto para ser u8lizado pelo cliente. Este
é um produto que deve ter sido testado e ter a qualidade.

• o número de pessoas (profissionais ou stakeholders envolvidos) podem

aumentar nas entregas posteriores, ou seja, conforme a complexidade do
produto aumente. Espera-se que primeiras entregas sejam produtos mais
simples –compreende a parte mais básica. Entregas posteriores compõem
funcionalidade mais complexas, mas que dependem das primeiras para
funiconarem.

• vantagem: melhor administração de risco – pode-se depender da entrega

de um hardware específico que só estará disponível numa data posterior.
Então, pode-se planejar que a parte do so2ware que dependerá dos dados
vindos desse hardware para um incremento futuro quando esse disposi8vo
já es8ver disponível para uso.
 Estrutura geral de Processo Incremental e Itera;vo
Tempo
Iterações
A8vidades Marcos Marcos
Fases

Levantamento Concepção Elaboração Construção Transição

de Requisitos cada fase
uma ou mais
Análise de Requisitos iterações
uma iteração: 2
Projeto a 6 semanas

final de uma iteração:

Implementação um incremento –
uma parte do sistema
Teste final

Implantação

cada fase está associada a um artefato

Processo Unificado cada fase é concluída com um marco, que é o
ponto onde decisões são tomadas e revistas.
 Fases do Processo Unificado
• concepção:
– idéia geral e escopo do são definidos. Planejamento inicial do
desenvolvimento e marcos entre as fases são estabelecidos.
• elaboração:
– requisitos do sistema são definidos e priorizados sua ordenação.
Iterações para a fase de Construção são definidas.
• construção:
– fase de maior iterações incrementais. Nesta fase partes do produto
podem ser entregues, o que envolve elaboração de manual do
usuário.
• Transição:
– usuários são treinados para interagir com o sistema. Envolve a
aceitação do usuário. Avaliação de gastos. Inicia Manutenção.
 Modelo Evolucionário

• existem categorias de negócio em que a mudança de

requisitos é constante, ou seja pode e ocorre durante o
desenvolvimento de um produto de so2ware.
• Modelo Evolucionário se caracteriza por um processo não
linear – o planejamento do produto deve ser reavaliado
durante o desenvolvimento do produto e significa que o
próprio produto pode ser alterado em relação a sua
concepção inicial.
– ideal para produtos que evoluem ao longo do tempo.
• Exemplo:
– Modelo Espiral
 Modelos não Prescri;vos

• modelos ágeis
– scrum
– EXtreme Programming (XP)
 Scrum

• processo itera8vo e incremental

• divide um projeto em pequenas partes (SPRINTS) executado por
equipes pequenas
– dividir para conquistar
– complexidade:
• produto a ser construído divido em subprodutos independentes que depois serão
integrados.
• cada subproduto é um entragável que quando finalizado é entregue ao cliente, que o
u8liza e fornece feedbacks.
• cada subproduto pode ser construído paralelamente a outro, de acordo com o tamanho
da equipe disponível.
– equipe
• divida em pequenos grupos, cada um responsável por um subproduto
• mais fácil a comunicação e controle da a8vidades de equipes pequenas (3 a 9 pessoas)
• Backlog do produto (Product backlog):
– iden8ficado o que precisa ser construído é elaborada uma lista de tudo que
precisa ser feito no ciclo de vida do projeto.
• O produto backlog é dividido em partes ou itens que podem ser feitos e
entregues de forma independente.

• Regra: em geral 80% do valor do produto para o usuário final está em

20% das funcionalidades do produto!

• Os itens (backlogs menores) ordenados de acordo com seu valor para o

negócio – assegura que as principais funcionalidades são feitas e
entregues primeiro
– vantagem: maior parte das funcionalidades (80%) não são muito necessárias - se
atrazos ou outros problems acontecerem, o impacto é pequeno!
 cerca de 15 minutos –

Estrutura do SCRUM
verifica o que foi feito no
dia anterior, o que deve
ser feito no dia e
reunião de 2 horas no máximo que a problemas que impactam
define o que será feito na spring. Se varia de 1 a finalização da sprint
s
repete a cada semana de duração da 4 semana
sprint

final da sprint –
par8cipam scrum master e stakeholders e
equipe para avaliar o processo clientes par8cipam
seguido na sprint e iden8ficar para demonstração
melhorias do produto e
feedback
 Scrum - Papeis

Product Owner: Scrum master Equipe

-Visão de retorno -Líder do processo -Implementadores
-Prioriza requisitos -Manter o foco no processo -MulAdisciplinar
-Planeja releases -Remover impedimentos -PraAcam autogestão
-Representante do cliente -Auxiliar na comunicação -Planejam as sprints
Teste de So0ware

Solange N. Alves de Souza 18

 Fundamentos de Teste de So0ware

• Obje8vo:
– encontrar problemas (erros)
– os requisitos estabelecem o que é um erro – falha que faz com que o
so2ware não se comporte como esperado.

Solange N. Alves de Souza 19

 Definições

• erro (error):
– diferença entre o resultado de uma computação e o resultado correto
ou esperado.
• defeito (fault):
– linha de código, bloco ou conjunto de dados incorretos que provocam
um erro observado.
• falha (failure):
– não funcionamento do so2ware, possivelmente provocado por um
defeito, mas com outras possíveis causas (ex. falha de leitura,
comunicação, etc.).
• engano (mistake):
– erro humano, é a ação que produz ou produziu um defeito no sofware

Solange N. Alves de Souza 20

 Depuração

• busca a causa do erro, ou seja, o defeito oculto que está

causando o erro.
• o fato de saber que não funciona, não significa saber em que
linha de código está o erro,
• O processo de depuração é a parte mais imprevisível de todo
o processo de desenvolvimento.
– Pode demorar 1 hora, 1 semana, 1 mês para ser diagnos8cado e
corrigido.

Solange N. Alves de Souza 21

 Categorias de testes
• Verificação:
– so2ware construído de acordo com o que foi especificado – atende
aos requisitos
– “Estamos fazendo a coisa do jeito certo?”
• Validação:
– so2ware construído atende às verdadeiras necessidades dos
interessados – os requisitos foram corretamente entendidos –
atendem realmente às necessidades?
– “Estamos fazendo a coisa certa?)
• Teste:
– a8vidade que permite realizar a verificação e validação do so2ware.

Solange N. Alves de Souza 22

• Área de Teste:
– definir conjuntos finitos e exequíveis de testes que, mesmo não
garan8ndo que o so2ware esteja livre de defeitos, consigam localizar
os mais prováveis, permi8ndo sua eliminação.

• Lei de Murphy
– Se alguma coisa pode sair errado, sairá (no pior momento possível)
– Se tudo parece estar indo bem é porque você não olhou direito
– A natureza sempre está a favor da falha oculta.

Solange N. Alves de Souza 23

 Fluxo de Informação de Teste
Especificação de Requisitos
Código-fonte

Configuração Avaliação
De So2ware Erros

Correções
Depuração
A8vidade
De teste
Dados da
Taxa de Erros

Configuração Resultados Confiabilidade

De Testes Esperados Modelo de Prevista
Confiabilidade

Plano de teste, Ferrramenta de

teste, casos de teste e resultados
esperados Solange N. Alves de Souza 24
• Os testes são realizados e todos os resultados ob8dos são
avaliados: os resultados ob8dos são comparados com os
resultados esperados.

• Dados errôneos encontrados: inicia-se a depuração.

Solange N. Alves de Souza 25

Os resultados de teste reunidos e avaliados, dão uma
indicação qualita8va da qualidade e confiabilidade do
so2ware.

Ø Erros Graves
Resultado Ø Erros facilmente corrigidos
dos Testes
Ø Erros não foram encontrados

Solange N. Alves de Souza 26

n Erros Graves:
F Se exigirem modificação de projeto e forem encontrados com
regularidade indicam: qualidade e confiabilidade do software
suspeitos.
F Testes adicionais são necessários.

Solange N. Alves de Souza 27

• Erros facilmente corrigíveis:
– Qualidade e confiabilidade aceitáveis ou,
– Os testes são inadequados para detectar erros
graves.

n Não foram encontrados erros:

n Atividade de teste não foi bem elaborada.
n Erros serão descobertos pelo usuário.
n Custo da correção: 60 a 100 vezes maior que fase de
desenvolvimento.

Solange N. Alves de Souza 28

 Projeto de Casos de Teste

• Teste de Caixa Preta

– Conhecendo-se a função específica que um produto deve
executar, testes podem ser realizados para demonstrar que cada
função é totalmente operacional.

• Teste de Caixa Branca

– Conhecendo-se o funcionamento interno de um produto, testes
podem ser realizados para garan8r que “todas as engrenagens
se encaixam”.

Solange N. Alves de Souza 29

Teste de Caixa Preta

Solange N. Alves de Souza 30

 TESTE DE CAIXA PRETA
difícil checar erros devido a funcionalidade e
erros devido a utilização de dados errados
entradas que provocam
comportamento anômalo
Entrada de Ed
dados de teste
testam a funcionalidade
a partir do estudo das preciso usar experiência
e conhecimento do
entradas e saídas
Componente domínio da aplicação

saídas que revelam a

presença de defeitos
Saída dos
Sd
resultados de teste

Solange N. Alves de Souza 31

• Trata-se de uma abordagem complementar que tem a
probabilidade de descobrir uma classe de erros diferente
daquela dos métodos de caixa branca.

• O teste de caixa preta tende a ser aplicado para

integração de módulos ou componentes.

• aplicado a funções ou a objetos

Solange N. Alves de Souza 32

 Testes de Caixa Preta tentam descobrir erros nas seguintes
categorias:

• funções incorretas ou ausentes;

• erros de interface;
• erros nas estruturas de dados ou no acesso a bancos de dados
externos;
• erros de desempenho;
• erros de iniciação e término de partes ou de todo o sistema.

Solange N. Alves de Souza 33

 Testes de caixa Preta

• Par8ção de Equivalência

Solange N. Alves de Souza 34

 Par;ção de Equivalência

• conjuntos de dados onde todos os membros do conjunto devem ser

processados de maneira equivalente.
• divide a entrada de um programa em classes de dados a par8r das quais
os casos de teste podem ser derivados.

entradas entradas válidas Especificação de Programa declara

inválidas que ele aceita de 4 a 10 entradas
de nos inteiros de 5 dígitos maiores
que 10 mil.
Componente

saídas

Solange N. Alves de Souza 35

 Especificação de Programa declara que ele aceita
de 4 a 10 entradas de nos inteiros de 5 dígitos
Diretriz: maiores que 10 mil.

F escolher casos de testes nos limites das partições e próximos

ao ponto médio da partição

Duas par8ções para o exemplo: 11

3 4 7 10

Menos de 4 Entre 4 e 10 Mais de 10

Número de valores de entrada
100.000
9.999 10.000 50.000 99.999

Menos de 10.000 Entre 10.000 e 99.999 Mais de 99.999

Valores de entrada

Solange N. Alves de Souza 36

Ex. Rotina de busca, que procura numa sequência de elementos um
determinado valor de chave. Ela retorna a posição deste elemento na
sequência

procedure Search (key:ELEM; T:SEQ of ELEM;

Found: BOOLEAN; L:ELEM_INDEX);
Pre-condition
duas partições:
-- a sequência tem pelo menos um elemento
1- entradas em que a sequência
T’FIRST<= T´LAST
contém o elemento chave
Pos-condition 2 - entradas em que a sequência
-- o elemento é encontrado e é referenciado por Lnão contém o elemento chave
(Found and T(L)=Key)
or
-- o elemento não está na sequência
(not Found and
not (exists i, T´FIRST >= i <=T´LAST, T(i) = Key))

Solange N. Alves de Souza 37

 Outras diretrizes para testes
1. Teste o so2ware com sequências que tenham um único valor
– o programa pode não trabalhar adequadamente com sequências que
tenham um único elemento.

2. U8lize sequências de tamanhos diferentes, em diferentes testes

– diminui chance de um defeito produzir uma saída correta.

3. Gere casos de teste de maneira que o primeiro, o médio e o úl8mo

elemento da sequência sejam acessados
– encontra problemas nos limites

mais duas partições:

3- sequência tem um único elemento
2 - sequência tem mais de um elemento
Solange N. Alves de Souza 38
 Par8ções de Equivalência para a ro8na de busca

Vetor Elemento
Um único elemento Está na sequência conjunto de
Um único elemento Não está na sequência
valores de
entrada não é
Mais de um elemento É o 1o da sequência
exaustivo
Mais de um elemento É o último da sequência
Mais de um elemento É o elemento médio na sequência
Mais de um elemento Não está na sequência não incluídos os
Sequência de entrada Chave (key) Saídas (Found, L) testes para verificar
17 17 verdadeiro, 1 se qtde, ordem de
17 0 falso, ??? entrada, tipo de dado
17, 29, 21, 23 17 verdadeiro, 1 dos parâmetros
41, 18, 9, 31, 31, 16, 45 45 verdadeiro, 7
estava correta
17,18, 21 , 23, 29, 41, 38 23 verdadeiro, 4
21, 23 29, 33, 38 25 falso, ??
Solange N. Alves de Souza 39
Testes de Caixa Branca ou Testes de
Estrutura

Solange N. Alves de Souza 40

 Testes de Caixa Branca
• É um método de projeto de casos de teste que usa
conhecimento da estrutura e da implementação para derivar
casos de teste.

Solange N. Alves de Souza 41

 O engenheiro de so0ware pode derivar os casos de
teste que:
• garantam que todos os caminhos independentes dentro de um módulo ou
método tenham sido exercitados pelo menos uma vez;
• exercitem todas as decisões lógicas para valores falsos ou verdadeiros;
• executem todos os laços em suas fronteiras e dentro de seus limites
operacionais;
• exercitem as estruturas de dados internas para garan8r a sua validade.

Solange N. Alves de Souza 42

 Testes de Caminho

q testar cada caminho independente num procedimento

// função de busca binária que considera um vetor de objetos ordenados e uma

chave e retorna um objeto com 2 atributos, chamados index – o valor do índice
do vetor e Found – um boleano que indica se uma chave está ou não no vetor.

// A chave será –1 se o elemento não for encontrado.

Solange N. Alves de Souza 43

 Implementação de uma rotina de busca binária em Java
Class BinSearch {
public static void search (int key, int [ ] elemArray, Result r)
{ int bottom = 0;
int top = elemArray.length – 1;
1 grafo de Fluxo para encontrar
int mid;
r. found = false; r.index = -1; os caminhos independentes
2 while (bottom <= top)
{ mid = (top + botttom) / 2;
3 if (elemArray [mid] == key)
grafo de fluxo para
{ r.index = mid;
essa rotina
r.found = true;
return;
} // if
else 5
{
4 if (elemArray [mid] < key) bottom = mid + 1;
else top = mid + 1;
}
6
7 } // while
8 } // search
9 } //BinSearch Solange N. Alves de Souza 44
 Complexidade Ciclomá;ca - CC

CC (G) = Número (ramos) – Número (nós) + 2 (McCabe, 1976)

• o número de casos de teste requerido para testar todos os caminhos

do programa é igual a complexidade ciclomá8ca

Solange N. Alves de Souza 45

 grafo de fluxo
• nós – representam decisões
• ramos – representam fluxo de controle

• declarações sequenciais (atribuições, chamadas de

procedimentos e declarações de E/S) podem ser
ignoradas na construção do fluxo.
• cada ramo de condição (if-then-else) é mostrado como
um caminho independente.
• loops indicado por seta mostrando o retorno ao nó da
condição do loop

Solange N. Alves de Souza 46

 Grafo de Fluxo para ro;na de busca binária
1
bottom > top while bottom <= top
2

if (elemArray [mid] == key

3

8 4 if (elemArray [mid] <key

9 5 6

7
• todas as declarações foram
1, 2, 8, 9 executadas pelo menos uma
caminhos independentes – 1, 2, 3, 8, 9 vez
complexidade ciclomática 1, 2, 3, 4, 5, 7, 2
• todos os ramos verdadeiro/
1, 2, 3, 4, 6, 7, 2, 8, 9
Solange N. Alves de Souza falso foram exercitados 47
 classe de
equivalência de Limites da classe de equivalência
busca binária

elementos < médio elementos > médio

casos de teste ponto médio

para a rotina
de busca

Vetor de entrada Chave (key) Saídas (Found, L)

17 17 verdadeiro, 1
17 0 falso, ???
17, 21, 23 , 29 17 verdadeiro, 1
9, 16, 18, 30, 31, 41, 45 45 verdadeiro, 7
17,18, 21 , 23, 29, 38, 41 23 verdadeiro, 4
7,18, 21 , 23, 29, 33, 38 21 verdadeiro, 3
12,18, 21 , 23, 32 23 verdadeiro, 4
21, 23 29, 33, 38 25 falso, ??
Solange N. Alves de Souza 48
 Testes de Estresse

• planejar testes que avaliem o comportamento do sistema em

condições de sobrecarga – confiabilidade e desempenho

• Obje8vo:
– testar o comportamento da falha:
• verificar se dados são corrompidos
• se interrompe os serviços para o usuário

Solange N. Alves de Souza 49