INF1027_Testes_e_Medidas

Prévia do material em texto

INF1027 Testes e Medidas de Software
Apresentação da Disciplina
Prof. Marcos Kalinowski | LES/DI/PUC-Rio
kalinowski@inf.puc-rio.br | www.inf.puc-rio.br/~kalinowski | @prof_kalinowski
Conteúdo enriquecido com material gentilmente cedido pelo Prof. Arndt von Staa
Apresentações
2020.1 2Marcos Kalinowski © LES/DI/PUC-Rio
• Professor de Engenharia de Software da PUC-Rio
– Orientador de Mestrado e Doutorado
– Coordenar de grupos de pesquisa em Engenharia de
Software do LES (http://www.les.inf.puc-rio.br)
– Co-coordenador da iniciativa ExACTa PUC-Rio de
Transformação Digital (http://www.exacta.inf.puc-rio.br)
– Membro do ISERN (International Software Engineering
Research Network – http://isern.iese.de)
– Principais áreas de atuação:
• Engenharia de Software Experimental
• Qualidade de Software
– Mais informações: http://www.inf.puc-rio.br/~kalinowski
• Quem são vocês?
– Experiência, interesses, ...
Objetivo
1. Habilitar o aluno a aplicar com eficácia conceitos e métodos 
de controle da qualidade de software 
2. Habilitar o aluno a organizar e gerenciar o processo de 
controle e garantia da qualidade de software
3Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Ementa
• Qualidade do Produto de Software
• Gerência da Qualidade de Software
– Medição da Qualidade de Software
• Verificação e Validação de Software
– Conceitos Iniciais
– Revisões de Software
• Revisões aos Pares, Inspeções e Walkthroughs
• Técnicas para Detecção de Defeitos
2020.1 4Marcos Kalinowski © LES/DI/PUC-Rio
Ementa
• Verificação e Validação de Software (cont.)
– Teste de Software
• Princípios, Estratégias e Fases de Teste de Software
• Processo de Teste de Software
• Técnicas de Teste de Software (Critérios Funcionais, Estruturais e 
Baseados em Defeitos)
• Tópicos em Teste de Integração
• Estratégias para Projeto, Execução e Controle dos Testes
• Aspectos Formais de Apoio aos Testes
• Teste Baseado em Modelos e Geração de Casos de Teste
• Automatização de Teste de Software
• Engenharia de Software Experimental e Medição
2020.1 5Marcos Kalinowski © LES/DI/PUC-Rio
Avaliação
• 2 provas, cabe salientar que não comparecer a uma prova resulta na nota 0.
– P1: 30/set – quarta-feira
– P2: 27/nov – quarta-feira
• 2 notas referentes a atuação ao longo do período, isto envolve as presenças, a 
participação ativa em sala e as atividades realizadas em sala.
– A1: Atuação até a P1.
– A2: Atuação entre a P1 e a P2.
• A seguir é apresentada a forma de cálculo dos dois graus e do grau final:
– G1 = ( P1 * 9 + A1 ) / 10.
– G2 = ( P2 * 9 + A2 ) / 10.
– Grau Final = if ( G2 >= 3 ) then ( G1 + G2 ) / 2 else ( G1 + 3 * G2 ) / 4
• Para ser aprovado o aluno deverá alcançar um Grau Final igual ou maior do que 5.
2020.1 6Marcos Kalinowski © LES/DI/PUC-Rio
Bibliografia
• Bibliografia básica:
– WAGNER, S.; "Software Product Quality Control". Springer. 2013.
– DELAMARO, M.E.; MALDONADO, J.C.; JINO, M.; "Introdução ao Teste 
de Software". Elsevier Editora, 2a Edição. 2016.
• Bibliografia complementar:
– MYERS, G.; BADGETT, T.; THOMAS, T.; SANDLER, C.; "The Art of 
Software Testing". Wiley, 3rd Edition, ISBN 978-1118031964. 2012.
– TIAN, J.; “Software Quality Engineering”, Wiley-Interscience, ISBN: 
978-0471713456. 2005.
– FENTON, N.E.; BIEMAN, J. “Software Metrics: A Rigorous and Practical 
Approach”. CRC, 3rd edition, ISBN: 978-1439838228, 2014.
7Marcos Kalinowski © LES/DI/PUC-Rio2020.1
INF1027 Testes e Medidas de Software
Qualidade do Produto de Software
Prof. Marcos Kalinowski | LES/DI/PUC-Rio
kalinowski@inf.puc-rio.br | www.inf.puc-rio.br/~kalinowski | @prof_kalinowski
Mas fazer software não é arte?
• Se o cantor/ator/pintor errar, a audiência fica chateada
• Se o engenheiro civil errar o prédio pode cair
• Se o médico errar o paciente pode morrer
• ...
• Se o desenvolvedor de software errar, o que pode 
acontecer?
Marcos Kalinowski © LES/DI/PUC-Rio2020.1 9
Caso 1: Therac-25
• Máquina de radioterapia controlada 
por computador
– Problema:
• Doses indevidas de radiação emitidas
– Causa:
• Interface com usuário inapropriada
• Documentação deficiente
• Software reutilizado sem ser adaptado 
para o novo hardware
• Software de sensores de falha com defeito
– Conseqüências
• Ao menos 5 mortes entre 1985 e 1987
http://sunnyday.mit.edu/papers/therac.pdf
2020.1 Marcos Kalinowski © LES/DI/PUC-Rio 10
Caso 2: Ariane 5
• Foguete lançador de satélites
– Problema:
• O foguete se auto-destruiu após o lançamento
– Causa:
• Software reutilizado sem ser adaptado para o novo 
hardware
• Ausência de testes em solo deste software
• Defeito apresentado em vôo
– Conseqüências
• Prejuízo de mais de US$ 370.000.000,00 em 1996
Dowson, Mark. 1997. The Ariane 5 software failure. 
SIGSOFT Softw. Eng. Notes 22, no. 2. 
2020.1 Marcos Kalinowski © LES/DI/PUC-Rio 11
Caso 3: Aeroporto Internacional de Denver
• Aeroporto com sistema automático de 
transporte de bagagens
– Problema: 
• Atraso na inauguração do aeroporto.
– Causa
• Aeroporto pronto no prazo, software de controle 
do sistema automático de transporte de bagagens 
não (com erros no software)!
• Obs: Aeroporto com 94 portões de embarque e 
desembarque, 6 pistas de pouso / decolagem
– Consequências:
• Atraso na abertura do aeroporto com custo total 
estimado em US$360 Milhões (33 Milhões por 
mês, 1200 vôos por dia com 100 mil passageiros 
por dia)
• 86 milhões para consertar o sistema
12
DEMARCO, T.; LISTER, T. (2003) Waltzing with Bears – Managing Risk on Software Projects. Dorset 
House. (ISBN: 978-0932633606).
2020.1 Marcos Kalinowski © LES/DI/PUC-Rio
Fazer Software Sério não pode ser Arte, 
deve ser Engenharia!
• Atualmente a vida das pessoas depende de 
software em praticamente todos os seus aspectos
– Software precisa ter qualidade
• Deve construído seguindo sólidos princípios de 
engenharia
Marcos Kalinowski © LES/DI/PUC-Rio2020.1 13
 Aumento da qualidade do produto
 Diminuição do retrabalho
 Maior produtividade
 Redução do tempo para atender o mercado
 Maior competitividade
 Maior precisão nas estimativas
Qualidade do processo (Expectativa)
Motivação para a Qualidade de Software
142020.1 Marcos Kalinowski © LES/DI/PUC-Rio
Características
 ad hoc - improvisado
 fortemente dependente dos profissionais
 indisciplinado
Consequências (esperadas)
 pouca produtividade
 qualidade de difícil previsão
 alto custo de manutenção
 risco na adoção de novas tecnologias
 ...
Processo Imaturo
152020.1 Marcos Kalinowski © LES/DI/PUC-Rio
Características
 processo conhecido por todos
 apoio visível da alta administração
 auditagem da fidelidade ao processo
 medidas do produto e do processo
 adoção disciplinada de tecnologias
Consequências (esperadas)
 papéis e responsabilidades claramente definidos
 acompanhamento da qualidade do produto e da 
satisfação do cliente
 expectativas para custos, cronograma, funcionalidades 
e qualidade do produto é usualmente alcançada
 ...
Processo Maduro
162020.1 Marcos Kalinowski © LES/DI/PUC-Rio
Pesquisa iMPS
• Pesquisa realizada anualmente para acompanhar e 
evidenciar resultados de desempenho nas empresas de 
software que adotaram o modelo de referência nacional 
para qualidade de processos de software, MPS-SW da 
iniciativa MPS.BR
• Disponível em http://www.softex.br/mpsbr/
17
Travassos, G.H., Kalinowski, M. “iMPS 2013: Evidências 
Sobre o Desempenho das Empresas que Adotaram o 
Modelo MPS-SW”. Campinas: SOFTEX, 2014 (ISBN: 978-
85-99334-75-1), 102p. 
2020.1 Marcos Kalinowski © LES/DI/PUC-Rio
Resultados de Desempenho das Empresas que 
Adotaram o MPS-SW
• Tendência a obter:
– Maior satisfação dos seus clientes
– Maior produtividade
– Maior capacidade para tratar projetos grandes
– Retorno do investimento (ROI)
– Melhoras no custo e na qualidade
182020.1 Marcos Kalinowski © LES/DI/PUC-Rio
Resultados de Desempenho das Empresas que 
Adotaram o MPS-SW
• Tendênciaa obter:
– Maior satisfação dos seus clientes
– Maior produtividade
– Maior capacidade para tratar projetos grandes
– Retorno do investimento (ROI)
– Melhoras no custo e na qualidade
192020.1 Marcos Kalinowski © LES/DI/PUC-Rio
Possíveis Ganhos na Evolução nos Níveis de 
Maturidade do MPS-SW
• Tendência a obter:
– Maior número de clientes
– Maior número de projetos
– Maior número de funcionários
– Maior capacidade para tratar projetos grandes
– Maior precisão nas estimativas de prazo
202020.1 Marcos Kalinowski © LES/DI/PUC-Rio
Possíveis Ganhos na Evolução nos Níveis de 
Maturidade do MPS-SW
• Tendência a obter:
– Maior número de clientes
– Maior número de projetos
– Maior número de funcionários
– Maior capacidade para tratar projetos grandes
– Maior precisão nas estimativas de prazo
212020.1 Marcos Kalinowski © LES/DI/PUC-Rio
Motivação
• Investir na melhoria do processo garante a qualidade do 
produto?
2020.1 22Marcos Kalinowski © LES/DI/PUC-Rio
Momento de Reflexão
• Um estudo informal relacionando defeitos em testes de 
aceitação com o nível de maturidade de empresas no CMMI-
Dev indicou tendência de melhora na qualidade do produto 
(Wagner, 2013)
• Resultados da pesquisa iMPS indicam tendência similar para 
o MPS-SW (Travassos e Kalinowski, 2014)
• mas ...
232020.1 Marcos Kalinowski © LES/DI/PUC-Rio
Motivação
• Diversos fatores influenciam a qualidade do produto e ela 
precisa ser avaliada e monitorada também diretamente. 
(Wagner, 2013)
– Requisitos de qualidade de produtos devem ser definidos e seu 
alcance monitorado ao longo da execução do projeto (Tian, 
2005).
2020.1 Marcos Kalinowski © LES/DI/PUC-Rio 24
Qualidade do Produto
• Qualidade de Software pode ser definida como o grau em 
que um sistema atende aos requisitos especificados e às 
expectativas dos clientes ou usuários (Wagner, 2013).
• Ou, de forma mais detalhada, a qualidade do produto de 
software pode ser definida como...
• Conjunto de características que devem ser alcançadas em 
determinado grau para que o produto atenda às 
necessidades de seus usuários (Rocha et al., 2001)
2020.1 25Marcos Kalinowski © LES/DI/PUC-Rio
Que características?
• Norma ISO 25010 – Software Product Quality Model
– Sobrepõe a antiga série ISO 9126
– Possui 8 características de qualidade principais para produtos 
de software e suas subcaracterísticas
2020.1 26Marcos Kalinowski © LES/DI/PUC-Rio
Figura retirada de (Mendoza et al., 2019)
Características da ISO 25010
27Marcos Kalinowski © LES/DI/PUC-Rio2020.1
ISO/IEC (2011)
Norma ISO 25010
2020.1 28Marcos Kalinowski © LES/DI/PUC-Rio
Modelo de qualidade do produto da ISO/IEC 25010 (ISO/IEC, 2011)
Norma ISO 25010
2020.1 29Marcos Kalinowski © LES/DI/PUC-Rio
Modelo de qualidade em uso da ISO/IEC 25010 (ISO/IEC, 2011)
A Norma ISO 25010 em Contexto
• Normas SQuaRE (Software product QUality Requirements
and Evaluation)
2020.1 30Marcos Kalinowski © LES/DI/PUC-Rio
Requisitos 
de 
Qualidade
2503n
Modelo de 
Qualidade
2501n
Gerenciamento 
da Qualidade 
2500n
Medições
2502n 
Avaliação
2504n
QPS (Modelo de Referência para Avaliação 
de Produtos de Software)
• Considera quatro dimensões: Engenharia de Software, 
Serviço, Qualidade do Produto e Organizacional
• Apresenta resultados em três níveis de atendimento da 
qualidade: Bronze, Prata e Ouro
• Rocha et al. (2018) descrevem resultados iniciais de sua 
implementação e avaliação em organizações Brasileiras
31Marcos Kalinowski © LES/DI/PUC-Rio2020.1
QPS (Modelo de Referência para Avaliação 
de Produtos de Software)
32Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Modelo QPS para Avaliação de Produtos de Software e sua relação com 
Normas Internacionais (Rocha et al., 2018)
Garantia e Controle da Qualidade de Produtos 
• Garantia da Qualidade
– Tem como propósito assegurar que os produtos de trabalho e a 
execução dos processos estejam em conformidade com os 
planos, procedimentos e padrões estabelecidos.
• Controle da Qualidade
– Verificação e Validação.
33Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Verificação e Validação
• Verificação
– Tem como propósito confirmar que cada serviço e/ou 
produto de trabalho do processo ou do projeto atende 
apropriadamente os requisitos especificados.
• Estamos construindo certo o produto? (Boehm, 1981)
• Validação
– Tem como propósito confirmar que um produto ou 
componente do produto atenderá a seu uso pretendido
quando colocado no ambiente para o qual foi 
desenvolvido.
• Estamos construindo o produto certo? (Boehm, 1981)
34Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Exercício de Fixação: Associe as Colunas
• Análise Estática
• Testes Unidade
• Testes de Integração
• Testes de Sistema
• Testes de Aceitação
• Revisões de Software
35Marcos Kalinowski © LES/DI/PUC-Rio2020.1
 Verificação
 Validação
Exercício de Fixação: Associe as Colunas
• Análise Estática
• Testes Unidade
• Testes de Integração
• Testes de Sistema
• Testes de Aceitação
• Revisões de Software
36Marcos Kalinowski © LES/DI/PUC-Rio2020.1
 Verificação
 Validação
Exercício de Fixação: Associe as Colunas
• Análise Estática
• Testes Unidade
• Testes de Integração
• Testes de Sistema
• Testes de Aceitação
• Revisões de Software
37Marcos Kalinowski © LES/DI/PUC-Rio2020.1
 Verificação
 Validação
Exercício de Fixação: Associe as Colunas
• Análise Estática
• Testes Unidade
• Testes de Integração
• Testes de Sistema
• Testes de Aceitação
• Revisões de Software
38Marcos Kalinowski © LES/DI/PUC-Rio2020.1
 Verificação
 Validação
Exercício de Fixação: Associe as Colunas
• Análise Estática
• Testes Unidade
• Testes de Integração
• Testes de Sistema
• Testes de Aceitação
• Revisões de Software
39Marcos Kalinowski © LES/DI/PUC-Rio2020.1
 Verificação
 Validação
Exercício de Fixação: Associe as Colunas
• Análise Estática
• Testes Unidade
• Testes de Integração
• Testes de Sistema
• Testes de Aceitação
• Revisões de Software
40Marcos Kalinowski © LES/DI/PUC-Rio2020.1
 Verificação
 Validação
Exercício de Fixação: Associe as Colunas
• Análise Estática
• Testes Unidade
• Testes de Integração
• Testes de Sistema
• Testes de Aceitação
• Revisões de Software
41Marcos Kalinowski © LES/DI/PUC-Rio2020.1
 Verificação
 Validação
Exercício de Fixação: Associe as Colunas
• Análise Estática
• Testes Unidade
• Testes de Integração
• Testes de Sistema
• Testes de Aceitação
• Revisões de Software
42Marcos Kalinowski © LES/DI/PUC-Rio2020.1
 Verificação
 Validação
Exercício de Fixação: Associe as Colunas
• Análise Estática
• Testes Unidade
• Testes de Integração
• Testes de Sistema
• Testes de Aceitação
• Revisões de Software
43Marcos Kalinowski © LES/DI/PUC-Rio2020.1
 Verificação
 Validação
Exercício de Fixação: Associe as Colunas
• Análise Estática
• Testes Unidade
• Testes de Integração
• Testes de Sistema
• Testes de Aceitação
• Revisões de Software
44Marcos Kalinowski © LES/DI/PUC-Rio2020.1
 Verificação
 Validação
45Marcos Kalinowski © LES/DI/PUC-Rio2020.1
• Boehm, B.W., Software Engineering Economics. Prentice-hall, 1981.
• ISO/IEC, ISO 25000 Software Product Quality - ISO/IEC 25010.
http://iso25000.com/index.php/en/iso-25000-standards/iso-25010, Official site 
(2011).
• Mendoza, I., Kalinowski, M., Souza, U., and Felderer, M., Relating Verification and 
Validation Methods to Software Product Quality Characteristics: Results of an 
Expert Survey. In Software Quality Days, 11th International Conference, SWQD 
2019, Vienna, Austria, January 15-18, 2019. 
• Rocha, A.R.C., Travassos, G.H., Santos, G., Reinehr, S., QPS - Modelo para 
Avaliação da Qualidade de Produtos de Software: Resultados 
Iniciais. Simpósio Brasileiro de Qualidade de Software, 2018.
• Rocha, A.R.C., Maldonado, J.C. and Weber, K.C., Qualidade de software: teoria e 
prática. São Paulo: Prentice-hall, 2001.
• Travassos, G.H., Kalinowski, M., iMPS 2013: EvidênciasSobre o Desempenho das 
Empresas que Adotaram o Modelo MPS-SW. Campinas: SOFTEX, 2014 (ISBN: 
978-85-99334-75-1), 102p. 
• Wagner, S., Software Product Quality Control. Springer, 2013.
Leituras Sugeridas
INF1027 Testes e Medidas de Software
Gerência da Qualidade de Software
Prof. Marcos Kalinowski | LES/DI/PUC-Rio
kalinowski@inf.puc-rio.br | www.inf.puc-rio.br/~kalinowski | @prof_kalinowski
Gerência da Qualidade de Software
• Gerência da Qualidade (ISO 25001) 
– Propósito: Gerência da qualidade de produtos com base em 
requisitos de qualidade e avaliação (Wagner, 2013)
– Diretamente alinhada com as definições de Tian (2005) e 
Wagner (2013)
• Ênfase na medição das atividades de garantia da qualidade, 
verificação e validação
47Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da Qualidade de Software 
• Qualidade no nível tático e operacional
48Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da 
Qualidade
Garantia da 
Qualidade
Verificação Validação
• Gerenciamento da qualidade envolve (Tian, 2005):
– Definir objetivos específicos de qualidade
– Planejar uma estratégia de qualidade
• Selecionar métodos apropriados de garantia da qualidade, 
verificação e validação (V&V)
• Selecionar medidas apropriadas para permitir a avaliação da 
qualidade
– Avaliar e controlar a qualidade
• Esta abordagem é consistente com a apresentada por 
Wagner (2013), que envolve as seguintes atividades:
– Identificar objetivos; Selecionar e integrar métodos de V&V; 
Acompanhar problemas; Monitorar atividades de V&V; Avaliar e 
controlar a qualidade
49Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da Qualidade de Software 
SQuaRE (Software product QUality
Requirements and Evaluation)
• Medidas objetivas referentes à garantia e o controle da qualidade formam 
a base para uma gerência da qualidade efetiva (Tian, 2005)
2020.1 50Marcos Kalinowski © LES/DI/PUC-Rio
Requisitos 
de 
Qualidade
2503n
Modelo de 
Qualidade
2501n
Gerenciamento 
da Qualidade 
2500n
Medições
2502n 
Avaliação
2504n
Gerência da Qualidade de Software 
• Qualidade no nível tático e operacional
51Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da 
Qualidade
Garantia da 
Qualidade
Verificação Validação
Gerência da Qualidade de Software 
• Qualidade no nível tático e operacional
52Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da 
Qualidade
Garantia da 
Qualidade
Verificação Validação
Garantia da Qualidade
• Avalia a conformidade do processo e do produto
– Visa assegurar que os processos planejados foram 
implementados e que os produtos seguem os padrões pré-
estabelecidos
– Quando não-conformidades são identificadas, elas devem ser 
tratadas e resolvidas no projeto
– Caso não sejam resolvidas no projeto, devem ser escalonadas 
para o nível adequado de gerência
53Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Garantia da Qualidade
• É fundamental que as avaliações sejam objetivas
– A objetividade é crítica para o sucesso do projeto
– A objetividade é conseguida com:
• O avaliador sendo independente do projeto (externo ao projeto)
• A utilização de um conjunto de critérios de avaliação
54Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Garantia da Qualidade
• Recorte de um checklist de garantia da qualidade
55Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da Qualidade de Software 
• Qualidade no nível tático e operacional
56Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da 
Qualidade
Garantia da 
Qualidade
Verificação Validação
Exercício
• Cite três exemplos de medidas que podem ser utilizadas 
para monitorar o processo de garantia da qualidade
57Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da Garantia da Qualidade
• Exemplos de medidas para gerir o processo de garantia da 
qualidade (Rocha et al., 2012):
– Taxa de não conformidades (NCs) em avaliações de qualidade 
no documento X (por exemplo, documento de requisitos)
– Taxa de NCs em avaliações de aderência ao processo X (por 
exemplo, gerência de requisitos)
– Esforço de retrabalho para corrigir NCs identificadas em 
avaliações de qualidade
– Taxa de NCs escalonadas
– Taxa de NCs escalonadas sem resolução
– Número de NCs identificadas na auditoria independente de 
qualidade
58Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da Qualidade de Software 
• Qualidade no nível tático e operacional
59Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da 
Qualidade
Garantia da 
Qualidade
Verificação Validação
Verificação
• Avalia se o produto definido reflete adequadamente os 
requisitos especificados (incluindo requisitos do cliente, 
produto e componentes do produto):
– Estamos construindo certo o produto?
• Principais métodos: Revisões e Testes
60Marcos Kalinowski © LES/DI/PUC-Rio2020.1
• Definição: Processo ou atividade para leitura de um 
artefato de software visando assegurar que ele cumpre sua 
especificação e atende às necessidades de seus usuários
– Validação e verificação estática de artefatos de software
– Proveem um bom meio para o gerente monitorar a qualidade 
do projeto
• Tipos de Revisão de Software:
– Revisão aos Pares
– Inspeções de Software
– Walkthroughs
Revisões de Software
61Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Revisões de Software
• Quando e em que tipos de artefato aplicar revisões de 
software?
•
Adaptado de Ackerman et al. (1989)
• Um relato simples e compreensível da aplicação de 
inspeções de requisitos em desenvolvimento incremental 
pode ser encontrado em Kalinowski et al. (2007)
62Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Revisão
Teste de Software
63Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Unidade
Integração
Perspectiva dos Projetistas e 
Desenvolvedores
Sistema
Aceitação
Perspectiva dos Clientes e Usuários
Teste de Sistema
• Objetivo:
– Executar o sistema sob ponto de vista de seu usuário final, 
varrendo as funcionalidades em busca de falhas
• Testes executados em condições similares àquelas que um 
usuário utilizará no seu dia-a-dia
• Um sistema divide-se em características:
– Funcionais
– Não-Funcionais
64Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Sistema = Funcional + Não-Funcional
Teste de Sistema
• Exemplos de tipos específicos de Teste de Sistema:
– Recuperação
• Força o software a falhar numa variedade de situações e verifica a 
capacidade de recuperação do produto 
– Segurança
• Verifica se os mecanismos de proteção construídos para o sistema 
irão de fato protegê-lo de alguma utilização ou intrusão imprópria.
– Stress
• Executa o sistema de forma a exigir recursos em quantidade, 
frequência ou volume anormais
– Desempenho
• Avalia o desempenho do software quando integrado ao sistema. 
Normalmente está associado ao teste de stress
65Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da Qualidade de Software 
• Qualidade no nível tático e operacional
66Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da 
Qualidade
Garantia da 
Qualidade
Verificação Validação
Exercício
• Cite três exemplos de medidas que podem ser utilizadas 
para monitorar o processo de verificação
67Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da Verificação
• Exemplos de medidas para gerir o processo de verificação 
(Rocha et al., 2012):
– Densidade de defeitos identificados em revisões por pares
– Esforço para a realização de revisões por pares
– Densidade de defeitos identificados nos testes de software
– Esforço para a realização de testes
– Esforço de retrabalho para a correção de defeitos
– Taxa de defeitos corrigidos
– Taxa de cobertura de funcionalidades dos testes
– Densidade de defeitos identificados após o software entrar em 
produção
– Esforço de retrabalho para a correção de defeitos de produção
– Tempo médio entre falhas
– Tempo médio para a correção de um defeito
68Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da Qualidade de Software 
• Qualidade no nível tático e operacional
69Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerênciada 
Qualidade
Garantia da 
Qualidade
Verificação Validação
Validação
• Avalia se o produto atende às necessidades de seus 
usuários
– Estamos construindo o produto certo?
• Normalmente envolve o usuário final e demais interessados
• Principais métodos: Revisões e Testes
70Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Validação
• Similaridades e Diferenças com Verificação
– Similaridades:
• Usa abordagens semelhantes (testes, inspeções, demonstrações e 
simulações)
– Diferenças:
• Necessidade de avaliar no ambiente de uso (operacional) do 
sistema ou em ambiente simulado
• Requer a participação do usuário final e demais interessados
• Na validação, a preocupação é garantir que o produto atende ao 
uso esperado, enquanto que na verificação, é garantir que atende 
os requisitos especificados
71Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da Qualidade de Software 
• Qualidade no nível tático e operacional
72Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da 
Qualidade
Garantia da 
Qualidade
Verificação Validação
Exercício
• Cite três exemplos de medidas que podem ser utilizadas 
para monitorar o processo de validação
73Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da Validação
• Exemplos de medidas para gerir o processo de validação 
(Rocha et al., 2012):
– Densidade de defeitos identificados em avaliação de requisitos
– Esforço de retrabalho para correção de defeitos nos requisitos
– Densidade de defeitos identificados nos testes de homologação
– Esforço de retrabalho para a correção de defeitos em testes de 
homologação
74Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da Qualidade de Software 
• Qualidade no nível tático e operacional
75Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da 
Qualidade
Garantia da 
Qualidade
Verificação Validação
Lembrando: É fundamental alinhar os métodos de V&V e as 
medidas com os requisitos de qualidade do produto!
Gerência da Qualidade de Software
76Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Monitorando Introdução & Detecção
0
0,5
1
1,5
2,0
2,5
3,0
Requirements Design Implementation Integration Acceptance
Testing
Fielded
Estimado
Introdução
Detecção
Real
Introdução
Detecção
D
ef
ei
to
s 
p
o
r 
U
n
id
ad
e 
d
e
 T
am
an
h
o
Gerência da Qualidade e Alta Maturidade
• Nos altos níveis de maturidade a gerência passa a ter um 
enfoque quantitativo (SOFTEX, 2012)
– No MPS-SW nível B a gerência quantitativa deve compreender 
processos críticos para os alcances dos objetivos 
organizacionais
– No CMMI-Dev nível 4 a gerência quantitativa deve se basear 
em requisitos de qualidade e desempenho
• Faz uso de ferramentas estatísticas, como gráficos de 
controle
• Permite a elaboração de modelos de desempenho para 
processos estáveis
77Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da Qualidade e Alta Maturidade
• Gráficos de Controle
• Modelos de Desempenho
78Marcos Kalinowski © LES/DI/PUC-Rio2020.1
ProblemasAPNormalizado = 0,0502 + 2,55 ProblemasGQNormalizado
Gráfico e modelo de desempenho extraídos de Montoni et al. (2007)
Observation
I
n
d
iv
id
u
a
l 
V
a
lu
e
161412108642
-2
-3
-4
-5
-6
_
X=-3,801
UC L=-1,652
LC L=-5,950
Observation
M
o
v
in
g
 R
a
n
g
e
161412108642
3
2
1
0
__
MR=0,808
UC L=2,640
LC L=0
I-MR Chart of ln(ProblemasGQNormalizado)
Gerência da Qualidade e Alta Maturidade
• Gráficos de controle podem ser utilizados como ferramenta 
gerencial mesmo que não se tenha ainda processos 
estabilizados
• Os gráficos mais indicados para dados de defeitos são os U-
charts (Kalinowski et al., 2012)
– Distribuição de Poisson
• Pontos fora de controle possuem causas atribuíveis e devem 
ser alvo de análise causal visando estabilizar o processo
• No MPS-SW nível A e CMMI-Dev nível 5 análise causal de 
defeitos deve ser aplicada visando melhoria contínua e não 
apenas estabilizar o processo
79Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da Qualidade: Quem Faz?
• Em empresas menores comumente a gerência da qualidade 
é realizada pelo próprio gerente do projeto
• Para empresas maiores é possível que se tenha um gerente 
dedicado exclusivamente à qualidade, com uma equipe que 
atende a diversos projetos
– Célula de Testes
– Fábrica de Testes
80Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Exercício
• Qual a tendência apresentada neste gráfico de controle do 
tipo U-chart? Este comportamento é positivo?
81Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gráfico extraído de Kalinowski et al. (2014)
Resposta
• Não é possível responder à pergunta somente com a 
informação apresentada (falta informação do esforço 
investido na detecção de defeitos)
82Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gráficos extraído de Kalinowski et al. (2014)
Considerações Finais
• Para uma Gerência da Qualidade efetiva:
– Estabeleça requisitos de qualidade para o produto
– Institucionalize garantia da qualidade
– Institucionalize inspeções de software
– Institucionalize testes
– Realize medições sobre as atividades de garantia e controle da 
qualidade considerando os requisitos de qualidade do produto
– Utilize resultados de medições para subsidiar decisões
– O uso de gráficos de controle e análise causal de defeitos não 
requer alta maturidade
83Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Leituras Sugeridas
• Kalinowski, M., Mendes, E., Travassos, G.H., An Industry Ready Defect Causal Analysis 
Approach Exploring Bayesian Networks. Software Quality Days, 6th International 
Conference, Lecture Notes in Business Information Processing, v. 166, p. 12-33, 2014. 
• Kalinowski, M., Card, D.N., Travassos, G.H., Evidence-Based Guidelines to Defect 
Causal Analysis. IEEE Software, vol. 29, no. 4, pp. 16-18, 2012.
• Kalinowski, M., Spínola, R. O., Dias-Neto, A. C., Bott, A., Travassos, G. H., Inspeções de 
Requisitos de Software em Desenvolvimento Incremental: Uma Experiência
Prática. Simpósio Brasileiro de Qualidade de Software, 2007. 
• Mendoza, I., Kalinowski, M., Souza, U., Felderer, M., Relating Verification and Validation 
Methods to Software Product Quality Characteristics: Results of an Expert Survey. 
In Software Quality Days, 11th International Conference, SWQD 2019, Vienna, Austria, 
January 15-18, 2019.
• Montoni, M., Kalinowski, M., Lupo, P., Abrantes, J. F., Ferreira, A.I.F., Rocha, A.R.C., Uma 
Metodologia para Desenvolvimento de Modelos de Desempenho de Processos para 
Gerência Quantitativa de Projetos de Software. Simpósio Brasileiro de Qualidade de 
Software, 2007.
• Rocha, A.R.C., Souza, G.S., Barcellos, M.P., Medição e Controle Estatístico de 
Processos. MCTi, 2012.
• Tian, J., Software Quality Engineering, IEEE Computer Society Press, 2005.
• Wagner, S., Software Product Quality Control, Springer, 2013.
84Marcos Kalinowski © LES/DI/PUC-Rio2020.1
INF1027 Testes e Medidas de Software
Verificação e Validação
Conceitos Iniciais
Prof. Marcos Kalinowski | LES/DI/PUC-Rio
kalinowski@inf.puc-rio.br | www.inf.puc-rio.br/~kalinowski | @prof_kalinowski
Conteúdo enriquecido com material gentilmente cedido pelo Prof. Arndt von Staa
Verificação e Validação (Relembrando)
• Verificação
– Tem como propósito confirmar que cada serviço e/ou 
produto de trabalho do processo ou do projeto atende 
apropriadamente os requisitos especificados.
• Estamos construindo certo o produto? (Boehm, 1981)
• Validação
– Tem como propósito confirmar que um produto ou 
componente do produto atenderá a seu uso pretendido
quando colocado no ambiente para o qual foi 
desenvolvido.
• Estamos construindo o produto certo? (Boehm, 1981)
86Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Porque Utilizar Métodos de V&V?
• A utilização destes métodos na indústria têm mostrado resultados 
positivos considerando tanto produtividade quanto qualidade
• Resultados de estudos experimentais evidenciam benefícios da 
utilização destes métodos no desenvolvimento de software
• Diversas evidências relacionadasa V&V foram obtidas ao longo dos 
anos de pesquisa em engenharia de software
872020.1 Marcos Kalinowski © LES/DI/PUC-Rio
Curiosidades
• O desenvolvimento de programas de boa qualidade sob a ótica da 
programação modular, provê um dos alicerces para desenvolver 
software correto por construção (von Staa, 2000)
• Prevenção de defeitos é usualmente mais eficaz que a remoção de 
defeitos (Mays, 1990) (Kalinowski et al., 2012)
• Qualidade do processo tende a melhorar a produtividade 
(Travassos e Kalinowski, 2014)
• Inspeções aumentam significativamente a produtividade, 
qualidade e estabilidade dos projetos (Fagan, 1976)
• Inspeções e Testes encontram diferentes tipos de defeitos (Hetzel, 
1976 & Meyer, 1978)
• Testes podem revelar a presença, mas não a ausência de defeitos 
(Dijkstra, 1970)
882020.1 Marcos Kalinowski © LES/DI/PUC-Rio
Curiosidades
• Um desenvolvedor não é indicado para testar seu próprio software 
(Weinberg, 1971)
• Aproximadamente 80% dos defeitos são provenientes de 20% dos 
módulos (Pareto, 1897) (Endres, 1975)
• Usabilidade é quantificável (Nielsen, 1994)
• Corrigir um defeito após a entrega do produto é frequentemente 
100 vezes mais caro do que corrigi-lo durante as atividades de 
requisitos e projeto do sistema (Boehm, Basili, 2001)
892020.1 Marcos Kalinowski © LES/DI/PUC-Rio
Defeitos de Software
• Erro Defeito Falha
– Erro
• Engano durante o desenvolvimento
– Defeito (Falta)
• Algum problema em um artefato de software
– Falha
• Problema encontrado ao executar o software
902020.1 Marcos Kalinowski © LES/DI/PUC-Rio
E Vulnerabilidades?
• Vulnerabilidade é um fragmento de um artefato, que, 
quando usado em condições peculiares, pode gerar uma falha
• ex. 1. proteção mal feita permite acesso a pessoas não autorizadas
• ex. 2. interface do usuário mal organizada induz erros de uso
• ex. 3. dados confidenciais armazenados de forma legível por 
terceiros permitem não autorizados a utilizar dados críticos
– na realidade vulnerabilidades são defeitos
• precisa-se procurar explicitamente por elas -> teste de 
vulnerabilidade 
91Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Confiabilidade e Manutenibilidade: 
Exemplos de Medidas
• MTBF – mean time between failures
– tempo médio entre falhas sucessivas
• MTTRc – mean time to recover
– tempo médio requerido para repor o sistema em 
funcionamento correto (recuperar) após uma falha 
• MTTRp – mean time to repair
– tempo médio requerido do momento em que é observada uma 
falha até versão corrigida do artefato estar disponível
• alternativa: até a versão corrigida estar em uso 
• MTTEv – mean time to evolve
– tempo médio requerido para evoluir ou adaptar o software após 
o registro de uma solicitação de alteração
92Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Na realidade o que interessa mesmo é a distribuição dos tempos, uma vez que tempos médios tendem a 
esconder potenciais problemas sérios -> mínimo , máximo , percentis (25, 50, 75 e 100%)
Defeitos de Software
93Marcos Kalinowski © LES/DI/PUC-Rio2020.1
(IEEE-1044, 2010)
Problema básico
• O desenvolvimento de software é um processo de aquisição 
e detalhamento de conhecimento
– no início o conhecimento é incompleto e abstrato
• do problema a resolver
• da solução proposta dada ao problema
– à medida que vai sendo desenvolvido o conhecimento vai 
sendo completado
• Consequentemente muitas solicitações de alteração ocorrem 
durante o desenvolvimento em virtude de novo 
conhecimento adquirido
94Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Dizeres romanos há bem mais de 2000 anos
• Errare humanum est
– errar é inerente ao ser humano
– Corolário 1: como humanos são falíveis e o 
desenvolvimento de software é intensivo em 
esforço humano, é utópico esperar que software 
não contenha defeitos
• Sed in errore perseverare dementis
– enquanto que perseverar no erro é próprio do louco
– Corolário 2: é sinal de incompetência ou obstinação 
burra não aceitar que erramos, não querer observar 
que erramos, não querer aprender com os erros 
nossos e de outros de modo que evitemos erros 
futuros
95Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Não existe software perfeito
• Não se pode esperar que sistemas não contenham 
defeitos 
– caso um sistema não contenha defeitos, não o 
saberemos
• algumas vezes podemos saber se módulos contêm defeitos 
ou não
– isso implica a necessidade de avaliar a corretude 
(controlar a qualidade) também durante a execução do 
sistema
• torna necessária a instrumentação do código
96Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Propagação de defeitos
• Defeitos podem ser inseridos na especificação, na 
arquitetura, nos projetos, no código, nas suítes de teste, ...
• Defeitos em artefatos antecedentes levam a erros em 
artefatos consequentes
– exemplo de defeitos na especificação: 
• esquecer requisitos relevantes 
– ex. esquecer segurança
– exemplos de defeito propagado para a arquitetura
• software não considera requisitos relevantes durante a definição da 
arquitetura (e.g., proteção dos dados do usuário contra uso 
indevido)
97Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Defeitos de Software
98Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Defeitos de Software
• A maior parte é de origem humana
• São gerados principalmente na comunicação e na 
transformação de informações
• Permanecem presentes nos diversos produtos de 
software produzidos e liberados
• A maioria encontra-se em partes do produto de 
software raramente utilizadas e/ou executadas
99Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Defeitos de Software
• Consequências:
– Estimativas de esforço e prazo deixam de fazer sentido
– Desperdício de recursos
– Produto final não atende as necessidades do usuário
– Corrigir defeitos após a entrega do produto pode ser até 
cem vezes mais caro que corrigi-los nas primeiras fases 
do desenvolvimento (em projetos menores, 5:1)
– Em projetos recentes de software, teríamos um esforço 
de retrabalho entre 40% e 50% do esforço total
(Boehm e Basili, 2001)
100Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Defeitos de Software
• Principal causa: 
– Tradução incorreta de informações
• Quanto antes a presença do defeito for revelada,
menor o custo de correção do defeito e maior a
probabilidade de corrigi-lo corretamente
– Atividades de V&V devem ser inseridas ao longo de todo o ciclo
de desenvolvimento
101Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Controle da qualidade versus evitar defeitos
• Controle da qualidade não leva a sistemas possuindo a 
qualidade desejada
– somente produz um laudo
– a melhoria da qualidade advém da eliminação dos defeitos 
observados
• retrabalho  mais custos 
• se não feito, gera dívida técnica
• Ao invés de fiar-se somente no controle da qualidade, por 
que não desenvolver de modo que se tenha a (quase) 
certeza de não ter introduzido defeitos?
– o mais próximo possível de correto por construção
102Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Defeitos de Software
Natureza do Defeito Definição
Omissão Informação necessária não incluída
Ambiguidade Informação passível de ter múltiplas 
interpretações.
Inconsistência Informações conflitantes
Fato Incorreto Informação que não é verdadeira para as 
condições especificadas.
Informação Estranha Informação desnecessária
103Marcos Kalinowski © LES/DI/PUC-Rio2020.1
• Taxonomia definida por Shull (1998) a partir do padrão 
IEEE (IEEE 830, 1998) para a natureza de defeitos em 
documentos de requisitos:
Natureza dos Defeitos
• Omissão
104Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Natureza dos Defeitos
• Ambiguidade
105Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Natureza dos Defeitos
• Inconsistência
106Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Natureza dos Defeitos
• Fato Incorreto
107Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Natureza dos Defeitos
• Informação Estranha
108Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Defeitos de Software• Taxonomia aplicável também a outros artefatos
109Marcos Kalinowski © LES/DI/PUC-Rio2020.1
(Travassos et al., 2001)
• A taxonomia para natureza de defeitos 
instanciada para projeto OO de alto nível
Natureza do 
Defeito 
Descrição 
Omissão Um ou mais diagramas de projeto que deveria conter algum conceito 
dos requisitos gerais ou do documento de requisitos não contêm uma 
representação para o conceito. 
Fato Incorreto Um diagrama de projeto contêm uma representação errada de um 
conceito descrito nos requisitos gerais ou no documento de requisitos. 
Inconsistência Uma representação de um conceito em um diagrama de projeto não 
concorda com uma representação do mesmo conceito no mesmo ou 
outro diagrama de projeto. 
Ambigüidade Uma representação de um conceito no projeto não está clara, e poderia 
levar o usuário do documento (projetista de baixo nível, desenvolvedor, 
etc.) a interpretar de forma diferente ou não entender o significado do 
conceito. 
Informação 
Estranha 
O projeto inclui informação que, enquanto talvez verdadeira, não se 
aplica a este problema e não deveria estar incluída no projeto. 
 
 
Defeitos de Software
110Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Defeitos de Software
• Considerações sobre documentos de requisitos:
– Primeiro artefato tangível a ser produzido
– Descreve todas as características e as funções que o 
software a ser desenvolvido deve possuir
– Atua como um contrato entre o cliente e o desenvolvedor
– Base para todas as etapas subsequentes do 
desenvolvimento
– Normalmente escrito em linguagem natural
111Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Tipos de Defeitos
• Existem diversas taxonomias para tipos de 
defeitos na literatura (Kalinowski et al., 2012)
• Exemplos de Taxonomias:
– Taxonomia do Padrão IEEE (IEEE-1044, 2010). Contendo 
os seguintes tipos de defeito: dados, interface, lógica, 
descrição, sintaxe, padrões, e outros
• Este padrão ainda complementa os tipos com a natureza (mode) do 
defeito, que pode assumir os seguintes valores: incorreto, omitido, 
e incluído sem ser necessário
112Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Tipos de Defeitos
• Exemplos de Taxonomias (cont.)
– Taxonomia de Orthogonal Defect Classificaton - ODC
(Chillarege et al., 1992), contendo os seguintes tipos de 
defeitos: interface, funcionalidade, empacotamento 
(build/package/merge), inicialização (atribuição), 
documentação, verificação (checking), algoritmo e 
temporal (timing/serialization)
• Além dos tipos de defeito, ODC considera ainda a natureza 
(qualifier) do defeito, de maneira consistente com o padrão IEEE, 
podendo assumir os mesmos valores (incorreto, omitido e incluído 
sem ser necessário)
113Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Informações sobre Defeitos
• Consenso a respeito das informações relevantes a 
serem coletadas sobre de defeitos de software de 
modo a apoiar monitoramento e análise causal de 
defeitos: 
– O momento (ou fase) em que o defeito foi introduzido
– O momento (ou fase) em que o defeito foi detectado
– Tipo de defeito
114Marcos Kalinowski © LES/DI/PUC-Rio2020.1
“Dimensões para classificar defeitos” 
(Card, 1998)
Informações sobre Defeitos
• Outras informações que, dependendo dos 
objetivos, podem também se mostrar úteis:
– Esforço de correção, severidade ou impacto;
– Localização (ou módulo);
– Trigger, que indica como o defeito foi detectado;
– Se o defeito foi introduzido durante o desenvolvimento 
de funcionalidades novas ou durante a manutenção. 
115Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Informações sobre Defeitos
• Um esquema mais completo de informações sobre 
defeitos pode ser encontrado em ODC (Chillarege
et al., 1992) e no padrão IEEE para classificar 
anomalias de software (IEEE-1044, 2010).
116Marcos Kalinowski © LES/DI/PUC-Rio2020.1
• ODC (Chillarege et al., 1992)
• Mais informações:
– Chillarege, R., Bhandari, I., Chaar, J., 
Halliday, M., Moebus, D., Ray, B., Wong, M.Y., 
“Ortogonal Defect Classification – A Concept 
for In-Process Measurement”, In: IEEE 
Trans. on Soft. Engi., vol. 18, pp. 943-956, 
1992.
Orthogonal Defect Classification (IBM)
117Marcos Kalinowski © LES/DI/PUC-Rio2020.1
(IEEE-1044, 2010)
Padrão IEEE para Anomalias de Software
118Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Gerência da Qualidade de Software
119Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Monitorando Introdução & Detecção
0
0,5
1
1,5
2,0
2,5
3,0
Requirements Design Implementation Integration Acceptance
Testing
Fielded
Estimado
Introdução
Detecção
Real
Introdução
Detecção
D
ef
ei
to
s 
p
o
r 
U
n
id
ad
e 
d
e
 T
am
an
h
o
Leituras Sugeridas
• Boehm, B., Basili, V., Software Defect Reduction Top 10 List. IEEE 
Software, 2001.
• Endres A., Rombach D., A Handbook of Software and Systems 
Engineering, Addison Wesley, 2003.
• IBM, Orthogonal Defect Classification v 5.2 for Software Design and 
Code, 2013.
• IEEE, IEEE Standard Classification for Software Anomalies. IEEE Std
1044-2009, C1 -15, 2010.
• Kalinowski, M., Card, D.N., Travassos, G.H., Evidence-Based Guidelines 
to Defect Causal Analysis. IEEE Software, 2012.
• Wagner, S., Software Product Quality Control, Springer, 2013.
120Marcos Kalinowski © LES/DI/PUC-Rio2020.1
INF1027 Testes e Medidas de Software
Revisões de Software
Prof. Marcos Kalinowski | LES/DI/PUC-Rio
kalinowski@inf.puc-rio.br | www.inf.puc-rio.br/~kalinowski | @prof_kalinowski
• Definição: Processo ou atividade para leitura de um artefato 
de software visando assegurar que ele cumpre sua 
especificação e atende às necessidades de seus usuários
• Objetivo:
– Realizar validação e verificação estática de artefatos de software
• Pode ser aplicada a qualquer artefato produzido ao longo do 
processo de desenvolvimento de software
Revisões de Software
122Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Revisões de Software
• Revisões aos pares (peer-reviews) aumentam a 
probabilidade de defeitos serem encontrados, 
quando comparadas com revisões feitas pelo próprio 
autor (desktop checking)
123Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Revisões de Software
• Quando e em que tipos de artefato aplicar revisões de 
software?
•
Adaptado de Ackerman et al. (1989)
• Um relato simples e compreensível da aplicação de 
inspeções de requisitos em desenvolvimento incremental 
pode ser encontrado em Kalinowski et al. (2007)
124Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Revisão
• Utilização na Prática
– Muitas organizações realizam revisões de software.
– Realização pouco sistematizada e potencial raramente é 
explorado
• Tipos de Revisão de Software:
– Revisão aos Pares
– Inspeções de Software
– Walkthroughs
Revisões de Software
125Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Inspeções de Software
• Tipo particular de revisão
• Tem sido o tipo de revisão de software mais estudado e utilizado
• Processo bem definido, introduzido em (Fagan, 1976)
• Evidências Experimentais:
– Redução do Esforço (Conradi et al., 1999)
– Aumento da Produtividade (Gilb, Graham, 1993)
– Redução do Tempo (Gilb, Graham, 1993)
– Redução dos Custos (Laitenberger, Atkinson, 1999)
– Capturam em média 60% dos defeitos (Boehm e Basili, 2001)
126Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Inspeções: um tipo particular de revisão
• Uma revisão é uma leitura crítica do artefato e da 
documentação complementar, anotando:
– os defeitos encontrados
– as omissões
– as dúvidas e dificuldades de compreensão
– as possibilidades de melhoria
• Uma inspeção é uma leitura crítica formalizada do 
artefato e da documentação complementar
– segundo um plano definido
– obedecendo a regras de leitura definidas
– envolvendo uma pequena equipe
– anotando defeitos, omissões, dúvidas e possibilidades de 
melhoria
127Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Inspeções de Software
• Benefícios e Custo de Inspeções:
– Inspeções vêm sendo utilizadas há quase quatro décadas
– Existe evidência experimentalde sua usabilidade e adequabilidade
– Proveem um bom meio para o gerente do projeto monitorar a 
qualidade e progresso do projeto
– Apresentam baixo custo devido ao fato do revisor não precisar investir 
muito tempo ou mesmo não demandar ferramentas sofisticadas para 
realizá-las
• Uma alta taxa de atividades de inspeção ao longo do 
processo pode representar de 5% a 10% do esforço de 
desenvolvimento
128Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Inspeções de Software: Benefícios
129Marcos Kalinowski © LES/DI/PUC-Rio2020.1
• Identificação de defeitos mais cedo
Inspeções de Software: Benefícios
• Implicação direta: custo de correção reduzido
130Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Inspeções de Software: Benefícios
• Inspeções em requisitos e projeto, conduzidas no JPL – Nasa
Jet Propulsion Laboratory (Miller,1990)
131Marcos Kalinowski © LES/DI/PUC-Rio2020.1
520 520
22 513 535
409 409
4 4
542 513 413 1468
Fase Requisitos
Fase Projeto
Fase Teste Unid.
Fase Teste Sist.
Total
Defeitos 
Req.
Defeitos 
Proj. Outros Total
Inspeções de Software: Benefícios
• Quantitativos:
– Primary Avionics Software System, JPL
• Inspeções em requisitos, projeto, código, plano de testes, 
especificações e procedimentos
• Taxa de Erros reduzidas de 2.25 para 0.08 defeitos/KSLOC
• Qualitativos:
– Aprendizado por experiência:
• Participantes aprendem padrões de defeitos
• Participantes aprendem bons padrões de desenvolvimento 
– No longo prazo ...
• Inspeções convencem os participantes a desenvolver 
software mais fácil de entender e manter
132Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Revisões e inspeções vs. testes
• Revisões e inspeções eliminam defeitos antes que se 
propaguem (poluam) para outros artefatos ou para o 
serviço a ser prestado
– um defeito na especificação provoca um erro ao criar a 
arquitetura (ou projeto), que se manifesta sob a forma de um 
defeito na arquitetura
– um defeito na arquitetura provoca um erro ao criar o projeto, 
que se manifesta sob a forma de um defeito no projeto
– um defeito em um projeto provoca um erro ao redigir o código, 
que se manifesta sob a forma de um defeito no código 
– a execução de um defeito no código pode causar falhas na 
execução
133Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Revisões e inspeções vs. testes
• Revisões devem ser praticadas a partir do primeiro 
momento do desenvolvimento
– reduzem significativamente o retrabalho inútil
• quanto maior a latência do erro, maior a poluição provocada pelo 
erro e mais cara e demorada fica a depuração
– porém não eliminam a possibilidade de defeitos passarem 
despercebidos
• testes serão sempre necessários
134Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Processo de Inspeção
135Marcos Kalinowski © LES/DI/PUC-Rio2020.1
• Processo de inspeção de software (Fagan, 1976)
Processo de Inspeção
• Planejamento
– Responsável: Moderador
– Tarefas:
• Definir contexto da inspeção (descrição da inspeção, como a 
preparação individual deverá ocorrer, documento a ser 
inspecionado, autor do documento, entre outros)
• Selecionar inspetores (recomenda-se utilizar entre 3 e 5 inspetores 
em uma inspeção)
• Distribuir material
• Preparação Individual
– Responsável: Inspetor
– Tarefas:
• Estudar os artefatos
• Fazer anotações sobre os artefatos
136Marcos Kalinowski © LES/DI/PUC-Rio2020.1
• Reunião de Inspeção
– Envolvidos: Moderador, Inspetores e Autor
– Tarefas:
• Leitura do documento, com a equipe discutindo possíveis defeitos 
(Duração recomendada 2 hrs)
• Produzir uma lista de defeitos
• Em casos de discordância a decisão sobre registrar um defeito ou 
não (falso positivo) é do moderador
• Retrabalho
– Responsável: Autor
– Tarefas:
• Corrigir os defeitos encontrados
Processo de Inspeção
137Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Processo de Inspeção
• Continuação
– Responsável: Moderador
– Tarefas:
• Analisar correções do autor e inspeção como um todo
• Reavaliar qualidade do artefato inspecionado
• Decidir sobre a necessidade de uma nova inspeção
138Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Processo de Inspeção de Humphrey
• Variante do processo tradicional de inspeção:
– Foco da Preparação Individual muda de entender o artefato 
para efetivamente encontrar seus defeitos
– Inspetores entregam lista de discrepâncias para o moderador 
antes de a reunião de inspeção se iniciar
– Objetivo da reunião é discutir diretamente as discrepâncias 
para classificá-las como defeito ou falso positivo
139Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Walkthroughs
• Alternativa com um processo menos rigoroso do que o de 
inspeções de software
• Papéis sugeridos:
– Líder, Autor, Escrivão e Revisores
• Procedimento:
– Os participantes são guiados através dos artefatos pelo líder 
(que eventualmente é o próprio autor) em uma reunião. 
Durante esta reunião devem interromper a apresentação caso 
encontrem defeitos
– Muitas vezes condições de entrada e saída e decisões são 
pressupostos pelo líder que segue sua linha de raciocínio 
durante a apresentação
140Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Walkthroughs
• Possuem custo aproximadamente igual ao de inspeções mas 
seus resultados são inferiores (SEI, 2005):
– Não providenciam resultados mensuráveis
– Não fornecem base para a aplicação de controle estatístico de 
processos, desejado para evoluir na maturidade de processos 
de software
• Podem ser utilizados para atividades de brainstorming, para 
explorar alternativas de projeto e resolução de problemas 
– Inspeções são mais focadas em encontrar defeitos
141Marcos Kalinowski © LES/DI/PUC-Rio2020.1
• O perfil dos inspetores selecionados para 
uma determinada inspeção afeta sua 
eficiência (Carver, 2003)
• Somente as discrepâncias encontradas por 
apenas um inspetor devem ser discutidas em 
equipe (Lanubile e Mallardo, 2003)
• O uso de técnicas de leitura apropriadas 
aumenta a eficiência da inspeção (Boehm, 
Basili, 2001)
Evidências
142Marcos Kalinowski © LES/DI/PUC-Rio2020.1
• O número de defeitos presentes no artefato 
pode ser estimado durante uma inspeção 
utilizando métodos de estimativa subjetivos 
(Biffl et al., 2003)
• A eficiência de uma reinspeção pode ser 
estimada a partir da eficiência da inspeção 
atual (Adams, 1999)
Evidências
143Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Dicas para Realizar uma Boa Inspeção
• Independente da abordagem utilizada, lembre-se:
– Revise o produto, nunca o desenvolvedor
– Mostre onde estão os problemas, mas não tente resolvê-los 
durante a inspeção
– Não tente se lembrar, faça anotações sempre
– Aprimore-se: Revise suas revisões anteriores!
144Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Dicas para Realizar uma Boa Inspeção
• Quanto ao processo:
– Defina uma agenda e cumpra-a rigorosamente
– Aloque recursos e tempo para a inspeção
– Limite o número de participantes e motive a preparação 
antecipada da inspeção
– Desenvolva uma lista de tópicos para cada produto que deverá 
ser revisado
– Forneça treinamento adequado a todos os revisores
– Limite o debate e a discussão
– Se for utilizado apoio ferramental, avalie se ele é adequado
145Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Exercício Prático
146Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Exemplo: Requisitos Funcionais (Recorte)
• Escopo: Permitir que os coordenadores de projeto, ou outros 
usuários designados por estes, possam realizar solicitações 
relativas à solicitação de passagens aéreas e de diárias através de 
formulários na web, viabilizando um controle mais efetivo sobre as 
solicitações.
• RF2: O software deve restringir a visibilidade do coordenador e de 
seus substitutos aos projetos associados a ele.
• RF9: O software deve permitir que o coordenador solicite 
Passagem Aérea.
• RF10: O software deve permitir que o coordenador solicite Diárias.
• RF18: O software deve manter um log de todas as solicitações 
realizadas, com os respectivos solicitantese data/hora da 
solicitação.
147Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Objetivo: Permitir ao coordenador agendar uma passagem aérea
Requisitos: RF2, RF9, RF18
Atores: Coordenador, Substituto
Prioridade: Alta
Trigger: O ator aciona a opção de solicitação de passagem aérea
Fluxo Principal: 1. O Sistema apresenta um formulário com as seguintes informações [RN1, RN2]:
- Listas com os projetos e fundos do coordenador
- Nome do passageiro
- Trecho
- Data de embarque
- Data de retorno
- Lista de companhias aéreas
- Código da reserva
2. O ator preenche o formulário.
3. O Sistema critica os dados fornecidos [A1][RN3, RN4], gera um código para a solicitação e a armazena
como “pendente” ou “espera” [RN7]. Em seguida é apresentado o código da solicitação e uma opção para
impressão da mesma [E1].
Fluxo Alternativo: [A1] Dados fornecidos não estão corretos
1. O Sistema mostra uma lista com os erros encontrados seguida do próprio formulário com os dados
previamente fornecidos. Volta para o passo 2 do fluxo principal.
Extensões: [E1] Ator solicita impressão da solicitação
Ver caso de uso “Imprimir Solicitação”
Regras de
negócio:
RN1 – O coordenador só poderá visualizar os projetos/fundos dos quais ele é coordenador. Caso essa
funcionalidade seja acessada por um substituto, deverão ser mostrados somente os projetos/fundos do
coordenador associados ao substituto.
RN2 – A seleção do passageiro poderá ser feita pelo CPF ou Nome das PF´s associadas ao coordenador,
através da digitação dessas informações (passageiro avulso) ou pela busca por CPF/Nome por todo o
conjunto de colaboradores cadastrados.
RN3 – Todos os dados do agendamento de passagem aérea são obrigatórios, com exceção da data de
retorno (retorno em aberto).
RN4 – As datas de embarque e retorno deverão ser maiores que a data corrente.
UC01 - Solicitar Passagem Aérea
Lista de Defeitos do UC01
2020.1 Marcos Kalinowski © LES/DI/PUC-Rio 149
UC02 - Solicitar Diárias
Objetivo: Permitir ao coordenador solicitar diárias
Requisitos: RF2, RF10, RF18
Atores:
Prioridade: Alta
Trigger: O ator aciona a opção de solicitação de diárias
Fluxo Principal: 1. O Sistema apresenta um formulário em branco com as seguintes informações [RN1 de UC09, RN1,
RN2, RN3, RN4, RN5, RN6, RN7, RN8, RN9]:
- Lista com os projetos e fundos do coordenador
- Nome do favorecido
- CPF do favorecido
- Trecho
- Tipo de diária (nacional ou internacional)
- Moeda
- Cotação (somente se for moeda estrangeira)
- Número de diárias
- Valor unitário da diária (na moeda selecionada)
- Valor total (em R$)
- Período da viagem (data de início e fim)
- Observações
- Forma de pagamento (cheque ou depósito em CC)
- Dados bancários: número e nome do banco, número e nome da agência, número da conta
corrente, cidade e UF.
- Lista com o local de aquisição da passagem
- Lista com o objetivo da viagem
- Descrição do objetivo da viagem
2. O ator preenche o formulário.
3. O Sistema critica os dados fornecidos [A1], gera um código para a solicitação e a armazena como
“pendente” ou “espera” [RN7]. Em seguida é apresentado o código da solicitação e uma opção para
impressão da mesma [E1].
Fluxo Alternativo:
Extensões: [E1] Ator solicita impressão da solicitação
Ver caso de uso “Imprimir Solicitação”
UC02 - Solicitar Diárias (cont.)
Regras de
negócio:
RN1 – Todos os dados da solicitação de diárias são obrigatórios, com exceção Moeda, Observações e
Dados bancários.
RN2 – Os dados bancários só serão obrigatórios se a forma de pagamento for Depósito em CC.
RN3 – O valor total para viagens nacionais deverá ser calculado como Número de diárias -Valor da
diária.
RN4 – O valor total para viagens internacionais deverá ser calculado como Número de diárias x Valor da
diária x Cotação na data corrente.
RN5 – O campo Moeda só é obrigatório para viagens internacionais.
RN6 – A data de início deve ser maior que a data de fim do período de viagem.
RN7 – A seleção do passageiro poderá ser feita pelo CPF ou Nome das PFs associadas ao coordenador,
através da digitação dessas informações (passageiro avulso) ou pela busca por CPF/Nome por todo o
conjunto de colaboradores cadastrados.
RN8 – Tanto o banco quanto a agência devem ser selecionados de uma lista. Caso a agência não exista
na lista, o solicitante deve fornecer o seu código, nome, cidade e UF. Caso a solicitação seja aprovada,
a agência será automaticamente cadastrada. Qualquer texto sem sentido só pra ver se leu até aqui, se
leu registre uma informação estranha.
RN9 – Caso o objetivo da viagem selecionado na lista seja “OUTROS”, o ator deve preencher a
descrição do objetivo da Viagem. Caso contrário essa informação é ignorada.
Lista de Defeitos do UC02
152Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Técnicas para Detecção de Defeitos
• Ad-hoc
• Checklist
• Técnicas de Leitura
– Exemplos:
• Requisitos
– Perspective Based Reading (PBR)
• Projeto
– Object Oriented Reading Techniques (OORTs)
• Código
– Stepwise Abstraction
– Abstract-driven Reading
• Análise Estática
153Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Ad-hoc
• Inspetor lê o documento de acordo com sua perspectiva.
• Experiência individual afeta o resultado final:
– Foco reside na especialidade do inspetor
– Produtividade individual
– Difícil garantir que inspetor leu o documento de forma 
adequada, pois cada um aplica “sua própria técnica”
• Não existe garantia de cobertura do documento como um 
todo
• Custo/Eficiência (# defeitos/tempo) pode ser adequado 
quando inspetores possuem experiência alta (> custo)
154Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Checklist
• Inspetor segue uma lista de itens com características a 
serem revisadas, mas ainda aplica leitura Ad-hoc para 
identificar os defeitos 
• Resultado final mais direcionado:
– Características de qualidade definidas à priori
– Produtividade individual 
– Difícil garantir que inspetor leu o documento de forma 
adequada, mesmo tendo sido definidas as características de 
qualidade a se procurar
• Cobertura do documento relacionada aos itens do Checklist
• Custo/Eficiência depende do Checklist e dos inspetores
• Checklist pode ser adaptado ou construído para capturar 
uma determinada especificidade
155Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Checklist (Exemplo para Requisitos)
1. Os requisitos exibem a distinção clara entre funções e dados?
2. Os requisitos definem todas as informações a ser apresentada aos usuários?
3. Os requisitos descrevem as respostas do sistema ao usuário devido à condições de erro? 
4. Cada requisito está descrito claramente, é conciso e está apresentado de forma não 
ambígua? 
5. O requisito é testável?
6. Existem requisitos implícitos ou ambíguos?
7. Existem requisitos conflitantes? 
8. Existem áreas não tratadas no documento de requisitos que precisam ser consideradas? 
9. Os requisitos de desempenho (tais como tempo de resposta, armazenamento de dados, 
etc.) foram definidos? 
10. Se os requisitos envolvem a descrição de processos de tomada de decisão complexos, 
eles estão descritos de forma a facilitar sua compreensão (i.e., tabelas de decisão, 
árvores de decisão, etc.)?
11. Os requisitos para executar as atualizações do software foram especificados? 
12. Existem requisitos que contêm algum nível desnecessário de detalhe do projeto? 
13. As restrições de tempo-real foram especificadas em detalhe suficiente? 
14. A precisão e acurácia dos cálculos foram especificadas? 
15. É possível desenvolver um completo conjunto de casos de teste baseado apenas na 
informação contida na especificação de requisitos? Se não, que informação está faltando? 
16. As restrições e dependências foram claramente descritas? 
17. O documento contém realmente toda a informação prometida em sua introdução? 
156Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Checklist (Real, utilizado para Projeto de 
Software)
157Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Técnicas de Leitura
• Motivação:
– desenvolvedores sãotreinados para escrever artefatos de 
software, mas raramente possuem habilidades para revisá-lo
– desenvolvedores confiam em técnicas ad-hoc e não seguem um 
procedimento bem definido
• Objetivos:
– fornecer um conjunto de instruções a serem seguidas pelos 
revisores para que os defeitos sejam detectados
– introduzir um formalismo que garanta que o procedimento 
possa ser seguido e repetido, possibilitando a melhoria 
contínua do processo de revisão
– reduzir a influência humana nos resultados (aproximar de uma 
atividade de Engenharia)
158Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Técnicas de Leitura
O que é uma técnica de leitura?
Um conjunto de instruções concretas dado ao leitor que diz 
como ler e o que procurar num produto de software
Mais especificamente, leitura de software é:
A análise individual de um artefato de software
ex., requisitos, projeto, código, planos de teste
para alcançar a compreensão necessária para uma 
tarefa em particular.
ex., identificação de defeitos, reutilização, manutenção
159Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Técnicas para Detecção de Defeitos
Técnica Notação Sistemático? Focado? Melhoria 
controlada?
Adaptável
?
Treinamento 
necessário?
Ad-Hoc Qualquer Não Não Não Não Não
Checklist Qualquer Parcialmente Parcialmente Parcialmente Sim Parcialmente
Técnicas 
de Leitura
Linguagem 
Natural
Sim Sim Sim Sim Sim
160Marcos Kalinowski © LES/DI/PUC-Rio2020.1
• Discussão: 
– Ad-hoc X Checklist X Técnica de Leitura
Leitura Baseada em Perspectiva (PBR)
• Se baseia no fato de existirem diferentes papéis durante o 
processo de desenvolvimento do software
• Provê um conjunto de instruções de acordo com o papel do 
“consumidor” de um artefato (usuário, projetista ou 
testador)
161Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Casos 
de 
Teste
SRS
Casos 
de Uso
Projeto
• Procurando Defeitos:
– Documento de requisitos atenderá às 
necessidades de seus futuros 
“consumidores”?
– Informações contidas no documento 
permitem que uma representação correta 
do sistema seja feita?
• Quando isto não acontece, uma discrepância 
é identificada e deve, então, ser categorizada. 
Leitura Baseada em Perspectiva (PBR)
• Fatos:
– inspeções com PBR encontram 35% mais defeitos que revisões 
ad-hoc (BOEHM e BASILI, 2001)
– a técnica ajuda a manter os inspetores focados durante toda a 
fase de identificação de discrepâncias
– PBR evita que os inspetores realizem inspeções superficiais
– a técnica altera (aprimora) o padrão de raciocínio dos 
inspetores
162Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Leitura Baseada em Perspectiva (PBR)
• Cada inspetor recebe um cenário que guia o seu trabalho.
– uma descrição procedural das atividades e questões que guiam 
o inspetor na utilização do documento sendo inspecionado
• Cada cenário consiste de duas partes:
– construir um modelo a partir do documento sendo revisado de 
forma a aumentar o entendimento
– responder questões sobre o modelo criado, focando em 
problemas de interesse para a organização
163Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Leitura Baseada em Perspectiva (PBR)
• Cada inspetor no time de inspeção lê o documento sob uma 
determinada perspectiva
• Benefícios:
– Foca a responsabilidade de cada inspetor
– Minimiza a sobreposição de responsabilidades
– Maximiza a cobertura dos defeitos
164Marcos Kalinowski © LES/DI/PUC-Rio2020.1
• O nível de detalhamento da técnica pode variar:
– Utilização pela primeira vez: baixo nível de detalhe para 
garantir o apoio
• Adaptáveis para níveis de experiência:
– Novatos: mais detalhes
– Especialistas: só precisam da perspectiva geral
• Uso em diferentes modelos de ciclo de vida:
– No modelo espiral, por exemplo, as primeiras iterações teriam 
um nível de detalhe menor já que a informação inicial é 
definida num nível mais alto de abstração
165Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Leitura Baseada em Perspectiva (PBR)
Técnicas de Leitura Orientada a Objetos 
(OORT) (Travassos et al., 1999)
• Aplicam-se à inspeção de projeto Orientado a Objetos:
– Família de técnicas de leitura que pode ser utilizada para ler 
artefatos de projeto OO de alto nível (descritos em UML) 
contra:
• Eles mesmos, garantindo consistência
• Requisitos e casos de uso, garantindo rastreabilidade dentro de um 
domínio com o objetivo de encontrar defeitos entre eles
2020.1 Marcos Kalinowski © LES/DI/PUC-Rio 166
Descrição dos 
Requisitos
Casos de Uso
Especificação de 
Requisitos
Projeto de Alto 
Nível
Diagrama 
de Classes
Descrição 
das Classes
Diagrama 
Transição 
de Estados
Diagramas de 
Interação
(Sequência)
Leitura Vertical
Leitura Horizontal
OORT’s: Artefatos Alvo
(Travassos et al., 1999)
2020.1 Marcos Kalinowski © LES/DI/PUC-Rio 167
OORT’s: Leitura Horizontal
• Assegura que todos os artefatos de projeto representam o 
mesmo sistema
• Projeto contêm visões complementares da informação 
– Estática (diagrama de classes)
– Dinâmica (diagramas de interação)
– Não é óbvio como comparar estas diferentes perspectivas
2020.1 Marcos Kalinowski © LES/DI/PUC-Rio 168
OORTs: Exemplo de leitura horizontal
OORT's – Leitura Horizontal v3.0
Leitura 1 – Diagramas de Seqüência x Classes
Objetivo: Verificar que um diagrama de classes para um sistema descreve as classes e seus 
relacionamentos
de forma que os comportamentos especificados nos diagramas de seqüência estão capturados 
corretamente.
Para fazer isto, você verificará primeiro que as classes e objetos especificados no diagrama de seqüência
aparecem no diagrama de classes. Então, você verificará que o diagrama de classe descreve os
relacionamentos, comportamentos e condições que capturam a dinâmica dos serviços como estão 
descritos
no diagrama de seqüência.
Entradas para o processo:
1. Um diagrama de classes (possivelmente dividido em pacotes) que descreve as classes de um sistema 
e
como elas estão associadas.
2. Diagramas de seqüência que descrevem as classes, objetos, e possivelmente atores de um sistema e
como eles colaboram para capturar os serviços do sistema.
I. Pegue um diagrama de seqüência e leia-o para entender que serviços do sistema estão 
descritos e como o sistema deveria implementar estes serviços.
ENTRADAS: Diagrama de Seqüência (DS).
SAÍDAS: Objetos do Sistema (marcados em azul no DS);
Serviços do Sistema (marcados em verde no DS);
Condições nos serviços (marcadas em amarelo no DS).
A. Para cada diagrama de seqüência, sublinhe os objetos do sistema e classes, e quaisquer atores, com 
uma caneta azul.
B. Sublinhe a informação trocada entre objetos (as setas horizontais) com uma caneta verde. Considere 
se esta informação representa mensagens ou serviços do sistema. Se a informação trocada está 
muito detalhada, para um nível de mensagens, você deverá abstrair várias mensagens juntas para 
entender que serviços elas estão fornecendo em conjunto. O exemplo 2 fornece uma ilustração de 
mensagens sendo abstraídas como serviços. Anote no diagrama de seqüência descrevendo estes 
serviços, e sublinhe-os também em verde. ...
2020.1 Marcos Kalinowski © LES/DI/PUC-Rio 169
OORT’s: Leitura Vertical
• Asseguram que os artefatos de projeto representam o 
sistema descrito pelos requisitos e casos de uso
• Podem ser aplicadas como base de atividades de validação
• Comparam documentos de diferentes fases do ciclo de vida
– Nível de abstração e detalhe são diferentes.
– Exploram a rastreabilidade semântica entre os documentos.
2020.1 Marcos Kalinowski © LES/DI/PUC-Rio 170
OORTs: Exemplo de leitura vertical
2020.1 Marcos Kalinowski © LES/DI/PUC-Rio 171
Stepwise Abstraction
• Primeira técnica de leitura. Criada por Harlan D. Mills em 1972
• O inspetor lê uma sequência de sentenças de código e as abstrai
em funções que essas sentenças computam
• As funções são então comparadas com a especificação
• Procedimento:
1. Leitura do código linha a linha para um entendimento conceitual de 
fragmentos de código
2. Conectar os fragmentospara obter o entendimento geral das funções
do sistema
3. Comparação das funções implementadas com a especificação
4. Repetir até que todo o código a ser analisado esteja abstraído e 
comparado com a especificação
172Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Leitura de código com stepwise abstraction encontra mais defeitos do 
que teste funcional e estrutural! (Basili e Selby, 1987)
Stepwise Abstraction: Exemplo
• Abstração:
– a=min(samples[])
– b=max(samples[])
173Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Abstract-driven Reading
• Adaptação por Dunsmore et al. (2002) para a leitura de código 
orientado a objetos
• Procedimento:
1. Determinar a ordem de leitura
a. Analisar as classes, identificando as dependências e os acoplamentos no 
sistema OO. Começar pelas classes com o menor número de dependências.
b. Analisar os métodos. Começar pelos métodos com o menor número de 
dependências.
2. Faça a leitura utilizando abstração
a. Para cada método, faça a engenharia reversa de uma especificação para o 
método. Compare a especificação obtida com a especificação da classe.
b. Rastreie e compreenda todas as classes referenciadas durante a leitura. Isto 
inclui ler métodos/classes e abstrações previamente criadas.
174Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Análise Estática
• Análise estática
– Análise estática é o processo de avaliar um sistema ou 
componente com base na sua forma, estrutura, conteúdo ou 
documentação
175Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Classificação de ferramentas de análise estática (Wagner, 2013)
ISO/IEC/IEEE 24765:2010: Systems and software engineering – vocabulary (2010) 
Análise Estática do Código
• Análise estática a partir de propriedades do código
– Exemplos
• a partir do grafo de chamadas envolvendo o programa
– que função ou método chama que outra função ou método?
– que catches podem tratar de um dado throw?
• reorganização de componentes
– existem arestas de corte no grafo de chamadas que permitam separar 
componentes?
• controle de tipos semânticos e unidades de medida
– ex. velocidade em m/s, nome de pessoa em 20 chars
176Marcos Kalinowski © LES/DI/PUC-Rio2020.1
arestas de corte – é um conjunto pequeno ( <= 3?) de arestas de um grafo conexo que, quando retirado 
transforma o grafo em duas ou mais partes desconexas
tipo semântico – informa o significado do dado, não somente a codificação
Análise Estática do Código: Interfaces
• Verifica compatibilidade entre interfaces
• Comumente não dispõe de recursos para controle de tipos 
semânticos
• Mesmo se não dispuser de uma ferramenta de controle de tipos 
semânticos
– sempre especifique, em comentários, a semântica e a unidade de 
medida de todos os parâmetros
– isso facilita muito a inspeção visual do uso das interfaces
– uso incorreto de interfaces é uma das frequentes causas de defeitos 
177Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Análise Estática do Código: Duplicação
• Copiar, colar e alterar código tende a ser nocivo
– duplica código, agora existem dois a serem mantidos
– se o código copiado contiver um defeito, as cópias também 
conterão
• aumenta desnecessariamente o esforço de manutenção
• aumenta o risco de manutenção incorreta
– duplicações também podem acontecer quando dois 
programadores se depararem com problemas similares
• Procure ferramentas de análise do código que procuram por 
duplicações (code clones)
– elimine as duplicações encontradas
• crie um método com parâmetros que implementa as diversas 
variantes do código base
178Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Ferramentas de Análise Estática 
• Ferramentas de análise estática, exemplos
– a primeira delas: lint para UNIX
– findbugs (java)
– cpplint (google c++)
– SonarQube (análise estática contínua)
– Existem inúmeras outras para as mais variadas plataformas 
(https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis)
179Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Leituras Sugeridas
• Basili, V.R., Selby, R.W., Comparing the effectiveness of software 
testing techniques. IEEE Transactions on Software Engineering, 1987.
• Dunsmore, A., Roper, M., Wood, M. Further investigations into the 
development and evaluation of reading techniques for object-
oriented code inspection. International Conference on Software 
Engineering (ICSE), 2002.
• Kalinowski, M., Travassos, G.H., Spínola, R.O., Dias-Neto, A.C., Bott, A., 
Inspeções de Requisitos de Software em Desenvolvimento 
Incremental: Uma Experiência Prática, VII Simpósio Brasileiro de 
Qualidade de Software, 2007.
• Kalinowski, M., Travassos, G.H., A Computational Framework for 
Supporting Software Inspections, 19th IEEE International Conference 
on Automated Software Engineering, 2004.
• Shull, F., Rus, I., Basili, V., 2000, How Perspective-Based Reading Can 
Improve Requirements Inspections, July, IEEE Software, pp. 73-79.
• Travassos, G. H., Shull, F., Fredericks, M., Basili, V. R., 1999, Detecting 
Defects in Object Oriented Designs: Using Reading Techniques to 
increase Software Quality, ACM Sigplan Notices. v.34, n.10, p.47 - 56.
• Wagner, S., Software Product Quality Control, Springer, 2013.
180Marcos Kalinowski © LES/DI/PUC-Rio2020.1
INF1027 Testes e Medidas de Software
Teste de Software:
Conceitos e Definições
Prof. Marcos Kalinowski | LES/DI/PUC-Rio
kalinowski@inf.puc-rio.br | www.inf.puc-rio.br/~kalinowski | @prof_kalinowski
Conteúdo enriquecido com material gentilmente cedido pelo Prof. Arndt von Staa
Teste de Software
“O software sempre será testado. Pode ser testado por 
você ou será testado pelo seu cliente/usuário.”
182Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Teste é um experimento controlado visando observar e 
registrar todas as falhas observadas ao executar casos de 
teste
Limitação intrínseca
• Teste somente sinaliza a ocorrência de falhas, nunca a sua 
ausência.
• E.W. Dijkstra
Marcos Kalinowski © LES/DI/PUC-Rio2020.1 183
Conceitos e Definições de Teste de Software
– Conceitos Básicos de Teste de Software
– Elementos do Teste de Software
– Níveis de Teste
– Desenvolvimento x Teste de Software
– Testes de Software em Normas e Modelos de Maturidade 
de Processo
– Processo de Teste de Software
184Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Teste e Depuração
• Teste: 
– Processo de executar um programa ou sistema com o objetivo 
de revelar a presença de falhas; ou, falhando nesse objetivo, 
aumentar a confiança sobre o programa
• Depuração: 
– É uma consequência não previsível do teste. Após revelada a 
presença da falha, o defeito deve ser encontrado e corrigido 
Depuração não é teste!
185Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Elementos do Teste de Software
• Caso de Teste:
– Descreve uma condição particular a ser testada
• Composto por valores de entrada, restrições para a sua execução 
e um resultado ou comportamento esperado
• Procedimento (Roteiro) de Teste:
– Descreve os passos necessários para a execução de um ou 
grupos de casos de teste 
186Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Elementos do Teste de Software
• Critérios de Cobertura dos Testes:
– Permitem a identificação de partes do programa que devem ser 
executadas para garantir a qualidade do software e indicar 
quando o mesmo foi suficientemente testado
• A Cobertura dos Testes determina o percentual de elementos 
testados em um programa
187Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Elementos do Teste de Software
• Rodada (Bateria) de Teste:
– Execução de todos os testes para uma versão do produto em 
um determinado ambiente
• Uma nova rodada de teste deve ser executada caso o critério de 
aceitação do produto não tenha sido atingido
• Incidentes de Teste:
– Evento ou comportamento diferenciado ocorrido durante a 
execução dos testes que requer investigação 
• Não há garantia que todo incidente seja uma falha, pois ainda 
precisa ser analisado
188Marcos Kalinowski © LES/DI/PUC-Rio2020.1
Objetivo dos Testes de Software
• Refutar