Aula08 Inspecao PDF

SCE221 – Verificação,
Validação e Teste
SCE702 – Teste e
Inspeção de Software
SCE221 – Verificação, Validação e Teste

Aula Anterior
SCE702 – Teste e Inspeção de Software
Revisões de Software
Revisões Técnicas
Formais
Reunião de Revisão
Técnica
Inspeção em DR Profa. Ellen Francine Barbosa

Inspeção em Profa. Simone do Rocio Senger de Souza
Código-Fonte
{francine, srocio}@icmc.usp.br
Conclusão
Exercı́cio de Fixação Instituto de Ciências Matemáticas e de Computação — ICMC/USP

Roteiro
SCE702 – Teste e Revisões de Software
Aula Anterior
Revisões Técnicas Formais
Revisões Técnicas Reunião de Revisão Técnica

Formais
Técnica
Inspeção em DR
Inspeção em
Inspeção em DR
Código-Fonte
Conclusão
Inspeção em Código-Fonte
Exercı́cio de Fixação
Conclusão
Aula Anterior...
SCE702 – Teste e
Qualidade de software.
Aula Anterior V&V envolvem atividades de análise estática e de
Revisões de Software análise dinâmica.
Formais
Análise Estática
Não requerem a execução propriamente dita do
Técnica produto.
Inspeção de Software Podem ser aplicadas em qualquer produto
Inspeção em DR intermediário do processo de desenvolvimento.
Inspeção em Documento de requisitos, diagramas de projeto,
Código-Fonte código-fonte, planos de teste, ...
Conclusão
As revisões são o exemplo mais clássico de análise
estática.
Revisões de Software I
SCE702 – Teste e
Meio efetivo para melhorar a qualidade de software.
Aula Anterior Filtro para o processo de Engenharia de Software.

Objetivo das Revisões
Tipos de Revisões
Podem ser aplicadas em vários pontos durante o
Revisões Técnicas desenvolvimento do software.
Formais
Maneira de usar a diversidade de um grupo de
Técnica pessoas para:
Apontar melhorias necessárias ao produto.
Inspeção em DR
Confirmar as partes de um produto em que uma
Inspeção em melhoria não é desejada ou não é necessária.
Código-Fonte
Conclusão
Realizar um trabalho técnico de qualidade mais
uniforme de forma a torná-lo mais administrável.
Objetivo das Revisões de Software I
SCE702 – Teste e Encontrar erros durante o processo de
desenvolvimento, de forma que eles não se
transformem em defeitos depois da entrega do
Aula Anterior
software.
Objetivo das Revisões Descoberta precoce dos erros.
Tipos de Revisões
Melhoria da qualidade já nas primeiras fases do
Formais processo de desenvolvimento.
Reunião de Revisão Aumento da produtividade e diminuição dos custos.
Técnica
Erros são detectados quando sua correção é mais
Inspeção de Software barata.
Inspeção em DR
Inspeção em
Código-Fonte
Conclusão
Objetivo das Revisões de Software II
SCE702 – Teste e
É uma oportunidade de treinamento.

Aula Anterior
Aprender por experiência.
Objetivo das Revisões Participantes aprendem as razões e padrões em
Tipos de Revisões
descobrir erros.
Formais Participantes aprendem bons padrões de
Reunião de Revisão desenvolvimento de software.
Técnica
Com o decorrer do tempo....
Inspeção em DR
A revisão auxilia os participantes a desenvolver
produtos mais fáceis de entender e de manter.
Inspeção em
Código-Fonte
Conclusão
Tipos de Revisões
Validação e Teste Discussão informal de um problema técnico.
SCE702 – Teste e
Apresentação do projeto de software para uma
Aula Anterior
audiência de clientes, administradores e pessoal
técnico.
Objetivo das Revisões
Tipos de Revisões
Revisões Técnicas Formais (RTF), as quais incluem
Formais
avaliações técnicas do software realizadas em
pequenos grupos.
Técnica Inspeção
Inspeção de Software Walkthrough
Inspeção em DR Peer-Review
Inspeção em
Código-Fonte
Conclusão
Revisões Técnicas Formais
SCE702 – Teste e Métodos de RTF:
Inspeção
Aula Anterior
Walkthrough
Formais
Peer-Review
Inspeção
Walkthrough
Peer-Review
Técnica
Inspeção em DR
Inspeção em
Código-Fonte
Conclusão
Inspeção
SCE702 – Teste e
Inspeção de Software Método de análise estática para verificar a qualidade
de um produto de software.
Aula Anterior
Revisões de Software Como detectar defeitos?

Formais
Inspeção
Lendo o documento.
Walkthrough Entendendo o que o documento descreve.
Peer-Review
Checando as propriedades de qualidade requeridas.
Técnica
Inspeção em DR
Inspeção em
Código-Fonte
Conclusão
Walkthrough
Validação e Teste Procedimento similar ao procedimento para
SCE702 – Teste e
Inspeção de Software condução de uma inspeção.
A diferença fundamental está na maneira como a
Aula Anterior sessão de revisão é conduzida.
Revisões de Software Em vez de ler o programa ou checar os erros por
Revisões Técnicas meio de um checklist, os participantes simulam sua
Formais
Inspeção
execução.
Walkthrough Papel adicional: testador.
Peer-Review
Elaborar um pequeno conjunto de casos de teste
Técnica
(em papel).
Monitorar e controlar os resultados obtidos.
Inspeção em DR
Inspeção em
Código-Fonte
Conclusão
Peer-Review
SCE702 – Teste e
Conduzida por pares de programadores.
Mesmo nı́vel de conhecimento.
Aula Anterior Aplicada ao código.
Revisões de Software Reuniões com duração de 1 a 2 horas.
Formais
Somente um programa ou parte dele (rotinas) deve
Inspeção ser revisado.
Walkthrough
Peer-Review Resultados são publicados em um relatório informal.
Técnica
Não faz parte da documentação oficial do projeto.
Inspeção em DR
Inspeção em
Código-Fonte
Conclusão
Reunião de Revisão Técnica I
SCE702 – Teste e
Independentemente do formato da RTF, toda

Aula Anterior
reunião de revisão deve seguir as seguintes
recomendações:
Formais Envolver de 3 a 5 pessoas.
Reunião de Revisão Deve haver uma preparação para a reunião.
Técnica
A preparação não deve exigir mais de 2 horas de
trabalho de cada pessoa.
Inspeção em DR
A reunião deve durar menos de 2 horas.
Inspeção em
Código-Fonte Deve-se focalizar uma parte especı́fica do software.
Conclusão Maior probabilidade de descobrir erros.
Reunião de Revisão Técnica II
SCE702 – Teste e
Aula Anterior
Formais
Técnica
Inspeção em DR
Inspeção em
Código-Fonte
Conclusão
Diretrizes para Revisão
SCE702 – Teste e
Inspeção de Software Revise o produto, não o produtor.
Fixe e mantenha uma agenda.
Aula Anterior Limite o debate e a refutação.
Revisões de Software Relacione as áreas problemáticas.
Formais
Faça anotações por escrito.
Reunião de Revisão Limite o número de participantes e insista em uma preparação
Técnica antecipada.
Desenvolva uma lista de conferência (checklist) para cada
Inspeção em DR produto que provavelmente será revisto.
Inspeção em Atribua recursos e uma programação de tempo para as
Código-Fonte
revisões.
Conclusão
Realize um treinamento significativo para todos os revisores.
Reveja suas antigas revisões.
SCE702 – Teste e
Método de análise estática para verificar a qualidade
Aula Anterior de um produto de software.
Pode-se inspecionar tanto produtos de software
Formais como também projetos de software.
Técnica
Diferencial está na seleção dos aspectos que devem
Etapas da Inspeção
ser considerados durante a revisão.
Vantagens da Inspeção
Técnicas de Leitura
Inspeção em Documentos de Requisitos.
Inspeção em DR
Inspeção em
Código-Fonte Inspeção em Código-fonte.
Conclusão
SCE702 – Teste e
Aula Anterior
Formais
Técnica
Inspeção em DR
Inspeção em
Código-Fonte
Conclusão
SCE702 – Teste e
Inspeção de Software Detecção antecipada de defeitos (inspeção de
requisitos).
Aula Anterior Aprende-se pela experiência.
Participantes aprendem os padrões e o raciocı́nio
Formais
utilizado na detecção de defeitos.
Participantes aprendem bons padrões de
Técnica desenvolvimento.
A longo prazo...
Vantagens da Inspeção A inspeção convence os participantes a
desenvolverem produtos mais compreensı́veis e mais
Inspeção em DR
fáceis de manter.
Inspeção em
Código-Fonte
As inspeções ajudam a integrar o processo de prevenção
Conclusão
de defeitos com o processo de detecção de defeitos.
Técnicas de Leitura para Inspeção I
SCE702 – Teste e
Como detectar defeitos?
Inspeção de Software Lendo o documento.
Entendendo o que o documento descreve.
Aula Anterior Verificando as propriedades de qualidade requeridas.
Problema:
Formais Em geral não se sabe como fazer a leitura de
Reunião de Revisão um documento!!!
Técnica
Razão:
Etapas da Inspeção Em geral, os desenvolvedores aprendem a escrever
documento de requisitos, código, projeto, mas não
Ad-hoc
aprendem a fazer uma leitura adequada dos mesmos.
Checklist
Inspeção em DR
Inspeção em
Código-Fonte
Conclusão
Exercı́cio de Fixação Solução:

Técnicas de Leitura para Inspeção II
SCE702 – Teste e
Aula Anterior
Fornecer técnicas de leitura bem definidas.
Formais Benefı́cios:
Técnica
Aumenta a relação custo/benefı́cio das inspeções.
Fornece modelos para escrever documentos com
Etapas da Inspeção maior qualidade.
Técnicas de Leitura Reduz a subjetividade nos resultados da inspeção.
Ad-hoc
Checklist
Inspeção em DR
Inspeção em
Código-Fonte
Conclusão
Técnicas de Leitura para Inspeção III
SCE702 – Teste e
Aula Anterior
Formais
Técnica
Ad-hoc
Checklist
Inspeção em DR
Inspeção em
Código-Fonte
Conclusão
Técnicas de Leitura para Inspeção IV
SCE702 – Teste e
O que é uma técnica de leitura?

Aula Anterior
Conjunto de instruções fornecido ao revisor dizendo
como ler e o quê procurar no produto de software.
Formais
Reunião de Revisão Algumas técnicas de leitura:

Técnica
Ad-hoc
Etapas da Inspeção Checklist
Técnicas de Leitura Leitura Baseada em Perspectiva (PBR)
Ad-hoc
Checklist
Stepwise Abstraction
Inspeção em DR
Inspeção em
Código-Fonte
Conclusão
Ad-hoc
SCE702 – Teste e
Os revisores não utilizam nenhuma técnica

Aula Anterior
sistemática de leitura.
Revisões Técnicas Cada revisor adota sua própria maneira de ler o
Formais
documento.
Técnica Desvantagens:
Inspeção de Software Depende da experiência do revisor.
Vantagens da Inspeção Não é repetı́vel.
Ad-hoc
Não é passı́vel de melhoria pois não existe um
Checklist procedimento a ser seguido.
Inspeção em DR
Inspeção em
Código-Fonte
Conclusão
Checklist
SCE702 – Teste e
Técnica que fornece diretrizes para ajudar o revisor
Aula Anterior
alcançar os objetivos de uma atividade de revisão
formal.
Revisões Técnicas Similar ao ad-hoc, mas cada revisor recebe um
Formais
checklist.
Técnica Os itens do checklist capturam lições importantes
Inspeção de Software que foram aprendidas em inspeções anteriores no
ambiente de desenvolvimento.
Técnicas de Leitura Itens do checklist podem explorar defeitos
Ad-hoc
Checklist caracterı́sticos, priorizar defeitos diferentes e
Inspeção em DR estabelecer questões que ajudam o revisor a
Inspeção em encontrar defeitos.
Código-Fonte
Conclusão
Inspeção em Documento de Requisitos
SCE702 – Teste e
Aula Anterior
Revisões de Software Benefı́cios da inspeção em Documento de

Formais
Requisitos:
Técnica Detecção antecipada de defeitos.
Produtividade e diminuição do custo.
Inspeção em DR
Taxonomia de Defeitos em DR
Leitura Baseada em Perspectiva
(PBR)
Inspeção em
Código-Fonte
Conclusão
SCE702 – Teste e
Inspeção de Software Detecção antecipada de defeitos.
Aula Anterior
Formais
Técnica
Inspeção em DR
(PBR)
Inspeção em
Código-Fonte
Conclusão
SCE702 – Teste e
Produtividade e diminuição do custo.
Aula Anterior
Formais
Técnica
Inspeção em DR
(PBR)
Inspeção em
Código-Fonte
Conclusão
Taxonomia de Defeitos em Documento de
Requisitos I
SCE702 – Teste e
Utilizada para classificação dos defeitos encontrados.
Situação ideal:
Aula Anterior A informação é transformada corretamente.
Formais
Técnica
Inspeção em DR
(PBR)
Inspeção em
Código-Fonte
Conclusão
Requisitos II
SCE702 – Teste e
Aula Anterior Tipos de erros:

Revisões de Software 1 A informação é perdida durante a transformação.
Formais
2 A informação é transformada incorretamente.
3 Informação estranha é introduzida.
Técnica 4 A mesma informação é transformada em diversas
Inspeção de Software ocorrências inconsistentes.
Inspeção em DR 5 A mesma informação possibilita diversas
Leitura Baseada em Perspectiva transformações inconsistentes.
(PBR)
Inspeção em
Código-Fonte
Conclusão
Requisitos III
SCE702 – Teste e
Aula Anterior
Formais
Técnica
Inspeção em DR
Classes de Defeitos:
(PBR)
Inspeção em
Defeitos de Omissão
Código-Fonte
Conclusão
Defeitos de Fato Incorreto
Defeitos de Inconsitência
Requisitos IV
SCE702 – Teste e
Aula Anterior
Revisões Técnicas Defeitos de Ambigüidade

Formais
Técnica
Defeitos de Informação Estranha
Inspeção em DR
(PBR)
Inspeção em
Código-Fonte
Conclusão
Defeitos de Omissão I
SCE702 – Teste e
Defeito de Omissão (O): qualquer informação
necessária que tenha sido omitida.
Exemplo 1 (Omissão de Funcionalidade). Considere
Aula Anterior
um sistema de biblioteca e os seguintes requisitos
funcionais (RF):
Formais RF2: O sistema deve solicitar a informação
Reunião de Revisão necessária para inserir um item bibliográfico: tı́tulo,
Técnica
autor, data, lugar, assunto, resumo, número, editor,
periódico, congresso.
Inspeção em DR
RF3: O sistema deve dar uma mensagem de alerta
(PBR)
quando o usuário tentar inserir um item incompleto.
Inspeção em Essa mensagem deve questionar o usuário se ele
Código-Fonte deseja cancelar a operação, completar a informação
Conclusão ou concluir a inserção como está.
Exercı́cio de Fixação Qual informação é necessária para possibilitar
uma inserção incompleta?
Defeitos de Omissão II
SCE702 – Teste e
Aula Anterior
Exemplo 2 (Omissão de Desempenho:)
Formais RNF1: O sistema deve fornecer os resultados tão
Reunião de Revisão rápido quanto possı́vel.
Técnica
Inspeção em DR Tão rápido quanto possı́vel?

(PBR)
Inspeção em
Código-Fonte
Conclusão
Defeito de Fato Incorreto
SCE702 – Teste e
Inspeção de Software Defeito de Fato Incorreto (FI): informação que
consta do artefato mas que seja contraditória com o
Aula Anterior conhecimento que se tem do domı́nio de aplicação.
Revisões Técnicas Exemplo: Considere um sistema de empréstimo

Formais
numa biblioteca e o seguinte RF:
Técnica
RF30: O sistema não deve aceitar devolução de
Inspeção em DR
livros se o usuário não estiver com a carteirinha da
Taxonomia de Defeitos em DR biblioteca no momento.
(PBR)
Inspeção em Para devolução de livros não é necessário

Código-Fonte
apresentar a carteirinha pois todas as
Conclusão
informações já estão registradas no sistema !
Defeito de Inconsistência
SCE702 – Teste e
Defeito de Inconsistência (I): informação que consta
Aula Anterior
do artefato mais de uma vez e em cada ocorrência
Revisões de Software ela é descrita de forma diferente.
Formais Exemplo: Considere um sistema de empréstimo
Reunião de Revisão numa biblioteca e o seguinte RF:
Técnica
RF5: O sistema não deve permitir perı́odos de
empréstimo maiores que 15 dias.
Inspeção em DR
Taxonomia de Defeitos em DR RF9: Professores podem retirar livros por um
(PBR) perı́odo de 3 semanas.
Inspeção em
Código-Fonte
Qual perı́odo deve ser considerado?
Conclusão
Defeito de Ambigüidade
SCE702 – Teste e
Inspeção de Software Defeito de Ambigüidade (A): quando a informação
pode levar a múltiplas interpretações.
Aula Anterior
Revisões de Software Exemplo: Considere um sistema de empréstimo

Revisões Técnicas numa biblioteca e o seguinte RF:
Formais
RF20: Se o número de dias que o usuário está em
Técnica atraso é menor que uma semana, ele deve pagar
Inspeção de Software uma taxa de R$ 1,00; se o número é maior que uma
Inspeção em DR
semana, a taxa é de R$ 0,50 por dia.
(PBR) Qual a taxa a ser paga se o perı́odo for de uma
Inspeção em
Código-Fonte
semana?
Conclusão
No primeiro caso, a taxa deve ser calculada por
dia?
Defeito de Informação Estranha
SCE702 – Teste e
Defeito de Informação Estranha (IE): qualquer

Aula Anterior
informação que, embora relacionada ao domı́nio, não
é necessária para o sistema em questão.
Formais
Reunião de Revisão Exemplo:

Técnica
RF15: Quando um novo livro é adicionado ao
acervo, ele permanece em uma prateleira especial
Inspeção em DR
por um perı́odo de um mês.
(PBR)
Inspeção em
Essa informação não é necessária ao sistema !!
Código-Fonte
Conclusão
Técnica de Leitura Baseada em Perspectiva
(PBR) I
SCE702 – Teste e Técnica de leitura proposta para detectar defeitos
em especificações de requisitos.
Aula Anterior
Faz com que cada revisor se torne responsável por
uma perspectiva em particular.
Revisões Técnicas Requer que o revisor crie abstrações de um produto
Formais
de software e responda algumas questões baseado na
Técnica análise da abstração.
Inspeção de Software As questões a serem respondidas e as regras para
Inspeção em DR criar a abstração são definidas para cada perspectiva
diferente.
(PBR)
Inspeção em Possibilita que o revisor melhore sua experiência em

Código-Fonte
diferentes aspectos do documento de requisitos.
Conclusão
Assegura que perspectivas importantes sejam
contempladas.
(PBR) II
Validação e Teste Cada revisor possui um cenário para guiar seu
SCE702 – Teste e
Inspeção de Software trabalho de revisão.
Todo cenário consiste de duas partes:
Aula Anterior
Construir um modelo do documento que está sob
Revisões de Software revisão a fim de aumentar o entendimento sobre o
Formais
mesmo.
Responder questões sobre o modelo, tendo como
Técnica foco itens e problemas de interesse da organização.
Inspeção em DR
(PBR)
Inspeção em
Código-Fonte
Conclusão
Exercı́cio de Fixação Cada revisor vai ler o Documento de Requisitos com

olhos diferentes.
(PBR) III
SCE702 – Teste e
Benefı́cios:
Inspeção de Software Determina uma responsabilidade especı́fica para
cada revisor.
Aula Anterior Melhora a cobertura de defeitos.
Formais
Técnica
Inspeção em DR
(PBR)
Inspeção em
Código-Fonte Várias leituras podem ser feitas no Documento de
Conclusão
Requisitos.
Exercı́cio de Fixação O projetista que usa o DR para gerar o projeto do
sistema.
(PBR) IV
SCE702 – Teste e
O testador que, com base no DR, deve gerar casos
de teste para testar o sistema quando este estiver
Aula Anterior
implementado.
O usuário que verifica se o DR está capturando toda
Formais funcionalidade que ele deseja para o sistema.
Técnica
Inspeção em DR
(PBR)
Inspeção em
Código-Fonte
Conclusão
(PBR) V
SCE702 – Teste e
Aula Anterior
Formais
Técnica
Inspeção em DR
(PBR)
Inspeção em
Código-Fonte
Conclusão
PBR – Visão do Usuário
SCE702 – Teste e
Definir um conjunto de funções que o usuário esteja
apto a executar.
Aula Anterior
Definir o conjunto de entradas necessárias para
executar cada função e o conjunto de saı́das que são
Formais
geradas pelas funções.
Reunião de Revisão Isso pode ser feito escrevendo todos os cenários
Técnica
operacionais que o sistema deve executar.
Inspeção em DR
Iniciar com os cenários mais óbvios até chegar nos
Taxonomia de Defeitos em DR menos comuns ou condições especiais.
(PBR)
Ao fazer isso, faça a você mesmo as perguntas a
Inspeção em
Código-Fonte seguir.
Conclusão Sugestão: Usar como modelo Casos de Uso.
PBR – Visão do Usuário: Questões
SCE702 – Teste e Todas as funções necessárias para escrever os cenários estão
especificadas no documento de requisitos ou na especificação
funcional?
Aula Anterior
As condições para inicializar os cenários estão claras e
Revisões de Software corretas?
Formais As interfaces entre as funções estão bem definidas e
compatı́veis (por ex., as entradas de uma função) têm ligação
Técnica com as saı́das da função anterior?
Inspeção de Software Você consegue chegar num estado do sistema que deve ser
Inspeção em DR evitado (por ex., por razões de segurança)?
Leitura Baseada em Perspectiva Os cenários podem fornecer diferentes respostas dependendo
(PBR)
de como a especificação é interpretada?
Inspeção em
Código-Fonte A especificação funcional faz sentido de acordo com o que
Conclusão você conhece sobre essa aplicação ou sobre o que foi
Exercı́cio de Fixação especificado em uma descrição geral?
PBR – Visão do Testador
SCE702 – Teste e
Para cada especificação funcional ou requisito gere
Aula Anterior
um conjunto de casos de teste que assegure que a
implementação do sistema satisfaz a especificação
Revisões Técnicas funcional ou o requisito.
Formais
Use sua abordagem de teste normal e critérios de
Técnica teste.
Ao fazer isso, faça a você mesmo as perguntas a
Inspeção em DR
seguir para cada teste.
(PBR) Sugestão: Usar como critérios de teste
Inspeção em Particionamento de Equivalência, Análise do Valor
Código-Fonte
Limite.
Conclusão
PBR – Visão do Testador: Questões
SCE702 – Teste e
Inspeção de Software Você tem toda informação necessária para identificar o item a
ser testado e o critério de teste?
Aula Anterior Você pode gerar um bom caso de teste para cada item,
baseando-se no critério?
Revisões Técnicas Você tem certeza de que os teste gerados fornecerão os
Formais valores corretos nas unidades corretas?
Técnica Existe uma outra interpretação dos requisitos de forma que o
programador possa estar se baseando nela?
Inspeção em DR Existe um outro requisito para o qual você poderia gerar um
Taxonomia de Defeitos em DR caso de teste similar, mas que poderia levar a um resultado
(PBR) contraditório?
Inspeção em A especificação funcional ou de requisitos faz sentido de
Código-Fonte
acordo com aquilo que você conhece sobre a aplicação ou a
Conclusão
partir daquilo que está descrito na especificação geral?
Inspeção em Código-Fonte
SCE702 – Teste e
Visa a encontrar defeitos no código-fonte, realizando
uma análise estática.
Aula Anterior
Vantagens:
Formais Programas ficam menos complexos.
Reunião de Revisão Subprogramas são escritos em um estilo consistente
Técnica e obedecem padrões estabelecidos.
Inspeção de Software O desenvolvimento de sistemas torna-se
Inspeção em DR transparente.
Inspeção em A estimativa e o planejamento tornam-se mais
Código-Fonte
Taxonomia de Defeitos em Código
confiáveis.
Stepwise Abstraction Facilita a manutenção, com o desenvolvimento de
Conclusão sistemas mais compreensı́veis e bem documentados.
SCE702 – Teste e
Duas classificações de defeitos em código:
Aula Anterior
Classificação I:
Defeitos de Omissão
Formais
Defeitos de Comissão
Técnica Classificação II:
Inspeção de Software Defeitos de Inicialização
Inspeção em DR Defeitos de Computação
Inspeção em
Defeitos de Controle
Código-Fonte Defeitos de Interface
Defeitos de Dados
Defeitos Cosméticos
Conclusão
Taxonomia de Defeitos em Código - I
SCE702 – Teste e
Defeitos de Omissão: Esquecimento de algum

Aula Anterior
elemento no programa.
Revisões Técnicas Exemplo: Falta de um comando que iria atribuir um

Formais
valor a uma variável.
Técnica
Defeitos de Comissão: Segmento de código
Inspeção em DR incorreto.
Inspeção em
Código-Fonte
Exemplo: Um operador aritmético errado é usado
Taxonomia de Defeitos em Código em uma expressão.
Conclusão
Taxonomia de Defeitos em Código - II I
SCE702 – Teste e
Aula Anterior
Defeito de Inicialização: Inicialização incorreta de
Revisões de Software uma estrutura de dados.
Formais
Exemplo: Atribuir um valor errado a uma variável.
Técnica
Defeitos de Computação: Qualquer computação
Inspeção em DR
incorreta para geração do valor de uma variável.
Inspeção em Exemplo: Um operador aritmético errado é usado em
Código-Fonte
Taxonomia de Defeitos em Código uma expressão de atribuição de valor para variável.
Conclusão
Taxonomia de Defeitos em Código - II II
SCE702 – Teste e
Defeito de Controle: Causa a execução de um
caminho de controle errado para um valor de
Aula Anterior
entrada.
Revisões de Software Exemplo: Predicado incorreto em um comando
Formais
IF-THEN-ELSE.
Técnica
Inspeção de Software Defeito de Interface: Quando um módulo usa ou faz

Inspeção em DR
suposições sobre dados que não fazem parte do seu
Inspeção em
Código-Fonte escopo.
Stepwise Abstraction Exemplo: Passagem de um argumento incorreto para
Conclusão um procedimento, ou quando um módulo assume
Exercı́cio de Fixação que irá receber um array inicializado com zero.
Taxonomia de Defeitos em Código - II III
SCE702 – Teste e
Defeitos de Dados: Uso incorreto de uma estrutura

Aula Anterior
de dados.
Revisões Técnicas Exemplo: Determinar incorretamente o último ı́ndice

Formais
de um array.
Técnica
Defeitos Cosmético: Erro de escrita no programa.
Inspeção em DR
Inspeção em
Exemplo: Uma mensagem de erro com erro de
Código-Fonte
escrita (ortografia, gramática).
Conclusão
Técnica de Leitura Stepwise Abstraction I
SCE702 – Teste e
Inspeção de Software Técnica de leitura utilizada para detectar defeitos
em código-fonte.
Aula Anterior Code-Reading
Formais Consiste em desenvolver abstrações funcionais a
Reunião de Revisão partir do código-fonte, para determinar a
Técnica
funcionalidade do programa.
Inspeção em DR
Inspeção em
Código-Fonte
Conclusão
Técnica de Leitura Stepwise Abstraction II
SCE702 – Teste e
Os revisores identificam subprogramas no
código-fonte e escrevem suas próprias especificações
Aula Anterior
para os subprogramas (abstrações de
Revisões de Software funcionalidade).
Formais
Reunião de Revisão As abstrações construı́das devem ser combinadas em

Técnica
uma abstração mais geral, até que se tenha
capturado a função completa do programa.
Inspeção em DR
Inspeção em
Código-Fonte Inconsistências são detectadas comparando a
Stepwise Abstraction especificação original com a especificação construı́da
Conclusão por meio das abstrações.
Técnica de Leitura Stepwise Abstraction III
SCE702 – Teste e
Aula Anterior
Formais
Técnica
Inspeção em DR
Inspeção em
Código-Fonte
Conclusão
Técnica de Leitura Stepwise Abstraction IV
SCE702 – Teste e
Aula Anterior
Formais
Técnica
Inspeção em DR
Inspeção em
Código-Fonte
Conclusão
Exemplo de abstrações de código:

Técnica de Leitura Stepwise Abstraction V
SCE702 – Teste e
Aula Anterior
Formais
Técnica
Inspeção em DR
Inspeção em
Código-Fonte
Conclusão
Princı́pios para o Processo de Leitura de
Código I
SCE702 – Teste e
1 Detectar como o programa irá falhar durante a
execução.
Construir as abstrações.
Aula Anterior
Determinar o comportamento de um componente
através da leitura.
Formais Determinar as dependências entre as funções
individuais no código. Normalmente, as funções
Técnica estão ordenadas no código, de modo que as
Inspeção de Software funções low-level (folhas) estão no ı́nicio do código
Inspeção em DR e as funções high-level (root) estão no final. Inicie
Inspeção em
aplicando a técnica de leitura de código nas
Código-Fonte funções folha caminhando em direção à raiz.
Desenvolver um entendimento da estrutura de
cada função individual, identificando as estruturas
Conclusão
elementares (seqüência, condições, atribuições,
repetições).
Princı́pios para o Processo de Leitura de
Código II
SCE702 – Teste e Marcar as estruturas identificadas, desenhando
quadrados para delimitá-las.
Combinar essas estruturas em outras mais externas
Aula Anterior até construir um quadrado que representa uma
Revisões de Software única função.
Revisões Técnicas Agregar as funções elementares de acordo com o
Formais fluxo de controle do programa.
Reunião de Revisão Isolar as falhas.
Técnica
Comparar as abstrações com a especificação para
detectar possı́veis falhas.
Inspeção em DR
Inspeção em
2 Isolar os defeitos que levariam a falhas.
Código-Fonte
Buscar as causas do comportamento inadequado
Stepwise Abstraction (defeitos) do programa.
Conclusão O entendimento do programa adquirido durante a
Exercı́cio de Fixação leitura facilita a localização do defeito.
Concluindo...
SCE702 – Teste e Inspeção não requer necessariamente a execução do
Inspeção de Software sistema e assim pode ser usada antes da
implementação estar concluı́da.
Aula Anterior Pode ser aplicada em qualquer representação do
Revisões de Software sistema (requisitos, projeto, dados de testes, ...)
Formais
Quando um erro é encontrado durante a inspeção, é
conhecida também sua natureza e localização.
Técnica Isso não ocorre com Teste de Software.
Inspeção e Teste são técnicas de V&V
Inspeção em DR
Inspeção em
complementares. Ambas devem ser usadas!!!
Código-Fonte Inspeções podem checar a conformidade com
Conclusão especificação mas não a conformidade com os
Exercı́cio de Fixação requisitos reais do cliente!
Inspeções não podem checar caracterı́sticas não
funcionais como desempenho, usabilidade....
SCE702 – Teste e
Aula Anterior
Formais
Técnica
Inspeção em DR
Inspeção em
Código-Fonte
Conclusão

Aula08 Inspecao PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula08 Inspecao PDF

Enviado por

Direitos autorais:

Formatos disponíveis

SCE221 – Verificação,

SCE221 – Verificação, Validação e Teste

Inspeção em DR Profa. Ellen Francine Barbosa

Exercı́cio de Fixação Instituto de Ciências Matemáticas e de Computação — ICMC/USP

Revisões Técnicas Reunião de Revisão Técnica

Aula Anterior Filtro para o processo de Engenharia de Software.

É uma oportunidade de treinamento.

Revisões de Software Como detectar defeitos?

Independentemente do formato da RTF, toda

Exercı́cio de Fixação Solução:

O que é uma técnica de leitura?

Reunião de Revisão Algumas técnicas de leitura:

Os revisores não utilizam nenhuma técnica

Revisões de Software Benefı́cios da inspeção em Documento de

Aula Anterior Tipos de erros:

Revisões Técnicas Defeitos de Ambigüidade

Inspeção em DR Tão rápido quanto possı́vel?

Revisões Técnicas Exemplo: Considere um sistema de empréstimo

Inspeção em Para devolução de livros não é necessário

Revisões de Software Exemplo: Considere um sistema de empréstimo

Defeito de Informação Estranha (IE): qualquer

Reunião de Revisão Exemplo:

Inspeção em Possibilita que o revisor melhore sua experiência em

Exercı́cio de Fixação Cada revisor vai ler o Documento de Requisitos com

Defeitos de Omissão: Esquecimento de algum

Revisões Técnicas Exemplo: Falta de um comando que iria atribuir um

Inspeção de Software Defeito de Interface: Quando um módulo usa ou faz

Defeitos de Dados: Uso incorreto de uma estrutura

Revisões Técnicas Exemplo: Determinar incorretamente o último ı́ndice

Reunião de Revisão As abstrações construı́das devem ser combinadas em

Exemplo de abstrações de código:

Você também pode gostar