4 testes de verificacao3

Prévia do material em texto

Testes de 
Verificação
PROF. CRISTINA FILIPAKIS
Características desejadas
Deve ser um processo sistemático
Fazer parte do processo de desenvolvimento
Ser realizado por pessoal especializado
Porém há...
◦ Minimização da sua importância
◦ Aplicação em poucos documentos
◦ Falta de planejamento e formalização
Características desejadas
� Nas revisões técnicas
◦ Erros de padronização são procurados
◦ E os erros de coerência, de funcionalidade, de clareza, podem ser 
deixados de lado
� Um processo de verificação deve:
◦ Obedecer regras
◦ Ter objetivos definidos
◦ Ter período estipulado
◦ Ter participação de pessoas com visões diferentes
Características desejadas
� Devem:
◦ Ser contínuos e freqüentes
◦ Possuir revisores treinados, experientes e que conheçam o domínio do 
problema
◦ Ter um moderador
◦ Ter reuniões curtas e focadas
◦ Identificar problemas, sem tentar resolvê-los
◦ Possuir uma conclusão formal, com produção de documento (com 
decisões e motivos para tais decisões)
Papéis em uma reunião de 
verificação
Moderador
Escrivão
Autor
Revisor 
Métodos Estruturados de 
Verificação
Fases de criação de 
documentos e suas Revisões
Revisão Isolada
Verificação individual por alguém que não seja o autor
Detecção prematura de erros
Tem por objetivo identificar o maior número possível de 
problemas
Antecipa a revisão formal
Acontece na fase de concepção do documento
Não deve acontecer de forma unilateral
Se houver desacordos, uma reunião deve ser proposta
Evitar revisões superficiais
Revisão Formal
Consiste na mais efetiva técnica de verificação
Presença de um grupo de revisores (4 a 7 membros)
O autor não deve conduzir a reunião
Preparação antecipada é exigida
Os membros do grupo devem ter visões, experiências e conhecimentos 
diferentes
Documentar é imprescindível
◦ Problemas detectados
◦ Correções
◦ Sugestões de melhoria
Após correções, ocorre nova revisão, porém focada somente no que foi 
modificado
Reunião de Acompanhamento
Forma de verificação menos formal
Não necessita de preparação do grupo de revisores
Tem por objetivo divulgar o que está sendo 
desenvolvido, familiarizando os revisores
Autor pode “manipular” reunião
Todos os desenvolvedores que dependem de tal 
artefato também devem estar presentes
Ao final, todos assinam um documento com o 
conteúdo apresentado
Auditorias
Concentram-se nas atividades críticas
Tem por objetivo avaliar se a equipe está respeitando o 
processo de desenvolvimento
São realizadas pelos auditores de qualidade
Os auditores devem estar atentos:
◦ às “quebras de processos”
◦ às desculpas de não adoção do processo
Equipes de Processo de Desenvolvimento de Software 
– SEPG devem determinar o processo e suas 
adaptações
Boas práticas para o processo 
de verificação
Planejar as reuniões de revisão
Preparar os profissionais
Executar a verificação de documentos
◦ Um tópico é definido
◦ Uma questão é levantada e discutida
◦ Os revisores confirmam a existência do erros
◦ O defeito é registrado e detalhado
◦ Outras questões são levantadas 
◦ Um novo tópico é definido
Aplicar checklist
Checklist
Cria uma abordagem única
Direciona a verificação, servindo como um “guia”
Para cada etapa do desenvolvimento são criadas 
checklists
Cada checklist possui diversos pontos de verificação
Critérios de finalização devem ser identificados
Fase 1 – Modelo de Negócios
• Modelar as necessidades e estabelecer uma 
macrovisão
• Identificar expectativas e exigências do cliente
• Estimar prazos e custos do projeto de software
Modelo de 
Negócios
• Verificar a aderência do modelo de negócios com a 
macrovisão
• Verificar as expectativas e exigências do projeto
• Verificar se as projeções foram realizadas de forma 
criteriosa e são realistas
Verificação 
de Negócios
• Modelagem de negócios assinada pelas diretorias e 
gerências envolvidas
• Proposta de projeto de software assinada pelas 
diretorias e gerências envolvidas 
Critérios de 
Finalização
Exemplo de checklist para fase 1
Checklist do Modelo de Negócios
Levantamento das necessidades do cliente
Todas as necessidades foram devidamente registradas. Sim ( ) Não ( )
Cada necessidade apontada possui uma descrição. Sim ( ) Não ( )
Existe o aceite do cliente para cada necessidade. Sim ( ) Não ( )
Definição das funcionalidades do software
Cada funcionalidade atende ao menos a uma necessidade identificada. Sim ( ) Não ( )
Cada funcionalidade possui exemplos que auxiliam seu atendimento. Sim ( ) Não ( )
Cada funcionalidade possui uma descrição. Sim ( ) Não ( )
Fase 2 – Requisitos
• Identificar os requisitos funcionais
• Identificar os requisitos não funcionais
• Identificar a arquitetura da aplicação
Especificação 
dos Requisitos
• Verificar consistência dos requisitos funcionais
• Verificar consistência dos requisitos não funcionais
• Verificar rastreabilidade entre requisitos e 
necessidades
Verificação 
dos 
Requisitos
• Especificações funcionais criadas e revisadas
• Especificações não funcionais criadas e revisadas
• Rastreabilidade entre requisitos e entre 
necessidades
Critérios de 
Finalização
Pontos Críticos na Análise de 
Requisitos
Completo: Todos os requisitos documentados.
Claro: Propósito definido.
Simples: Definição facilmente entendida.
Preciso: Sem ambiguidades.
Consistente: Sem conflitos com outros requisitos.
Relevante: Deve pertencer ao escopo.
Testável: Deve ter sido adequadamente descrito, projetado e implementado.
Factível: Deve ser viável.
Exemplo de checklist para fase 2
Checklist de Requisitos
Diagrama de Caso de Uso
Existe um modelo de caso de uso para cada subsistema identificado. Sim ( ) Não ( )
Todos os casos de uso estão adequadamente descritos. Sim ( ) Não ( )
Todos os atores estão adequadamente representados. Sim ( ) Não ( )
Levantamento dos requisitos
Cada caso de uso representa um requisito funcional. Sim ( ) Não ( )
Requisitos foram avaliados por importância, volatilidade e criticidade. Sim ( ) Não ( )
Especificações funcionais
As especificações contemplam os fluxos básicos, alternativos e 
exceções.
Sim ( ) Não ( )
As especificações contemplam pré e pós-condições. Sim ( ) Não ( )
Fase 3 – Análise e Modelagem
• Modelar uma solução que suporte todos os 
requisitos
• Modelar uma arquitetura flexível
Análise e 
Modelagem
• Verificar consistência da arquitetura com a 
solução
• Verificar a aderência de requisitos funcionais e 
não funcionais com a solução
Verificação da 
Análise e 
Modelagem
• Avaliar se todos os requisitos funcionais e não 
funcionais contemplam a solução
• Avaliar se a arquitetura suporta o crescimento e 
a segurança desejados.
Critérios de 
Finalização
Exemplo de checklist para fase 3
Checklist de Diagramas UML
Diagrama de Classes
Todas as classes possuem nome e descrição. Sim ( ) Não ( )
Todos os atributos possuem nome e descrição. Sim ( ) Não ( )
Todos os métodos possuem nome e descrição Sim ( ) Não ( )
Fase 4 – Implementação
• Traduzir os modelos em código-fonte.
• Traduzir os requisitos de negócios em código-
fonte.
Implementação
• Garantir que o código está compatível com os 
modelos.
• Garantir as normas e padrões de 
desenvolvimento.
• Garantir reduzido nível de complexidade.
Verificação da 
Implementação
• Comparar os modelos com o código-fonte
• Avaliar as mensagens apresentadas ao usuário 
final
• Inspecionar a legibilidade do código
Critérios de 
Finalização
Exemplo de checklist para fase 4
Checklist do Código-fonteTodas as classes, atributos e métodos do modelo foram 
implementadas.
Sim ( ) Não ( )
Nenhuma mensagem apresenta erros gramaticais. Sim ( ) Não ( )
Todas as mensagens são claras e objetivas. Sim ( ) Não ( )
Todas as declarações de variáveis estão no início da rotina. Sim ( ) Não ( )
Todas as rotinas estão documentadas. Sim ( ) Não ( )
Análise de Normas e Padrões 
de Codificação
Critérios analisados durante a 
inspeção do código
Tolerância a erros
por severidade
Alta Média Baixa
Banco de Dados Nenhuma Nenhuma Nenhuma
Lógica Nenhuma Nenhuma Nenhuma
Performance Nenhuma 10 erros 10 erros
Portabilidade Nenhuma Nenhuma Nenhuma
Usabilidade 5 erros 10 erros 20 erros
Análise da complexidade do 
Código
Complexidade 
Ciclomática
Avaliação da 
Complexidade
Esforço de 
Manutenção e 
Teste
Probabilidade de 
Inserção de Erros
< 5 Simples Baixo esforço 1%
5 – 10 Moderada Médio esforço 5%
11 – 20 Difícil Grande esforço 10%
21 – 50 Muito difícil Muito complexo 30%
> 50 Impossível de 
testar
Refazer --
Métricas de qualidade definidas por McCabe.
Situação aceitável
Complexidade 
Ciclomática
Avaliação da 
Complexidade
Percentual Máximo
Permitido
< 5 Simples 100%
5 – 10 Moderada 20%
11 – 20 Difícil 5%
21 – 50 Muito difícil Não permitido
> 50 Impossível de testar Não permitido