Download - Verificação, Validação e Teste de Software
Verificação, Validação e Testes de Software
Pós-Graduação em Engenharia de SoftwareProf. Camilo Almendra, MsC.
Junho/2009
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Conceitos básicos O Negócio da V&V Modelo em V Planejamento Revisão técnica Tipos de testes Trabalho Final
Agenda
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Palestrante
Graduado em Ciência da Computação/UFC, 1999 Mestre em Ciência da Computação/UFC, 2003 Experiência em empresas com processos reconhecidos
CMMi-3 (C.E.S.A.R/Recife, Atlântico/Fortaleza) Experiência em liderança de equipes e projetos de
software embarcado. Atualmente
Analista de Sistemas no Atlântico, atuando como líder técnico Membro do Grupo de Engenharia de Processos
Conceitos Básicos
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Conceitos Básicos
Processo de software Processo de software, ou processo de engenharia de software, é uma
seqüência coerente de práticas que objetiva o desenvolvimento ou evolução de sistemas de software. Estas práticas englobam as atividades de especificação, projeto, implementação, TESTES e caracterizam-se pela interação de ferramentas, pessoas e métodos.
Qualidade “Qualidade é a totalidade das características de uma entidade que lhe
confere a capacidade de satisfazer às necessidades explícitas e implícitas” (NBR ISO 8402)
Arquitetura “A organização fundamental de um sistema, compreendendo seus
componentes, seus relacionamentos uns com os outros e com o ambiente, e os princípios que governam seu desenho e sua evoluação”(IEEE)
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Conceitos Básicos
Verificação Processo de avaliação de um sistema ou componente para
determinar se os artefatos produzidos satisfazem às especificações determinadas no início da fase.
“Você construiu corretamente?” Validação
Processo de avaliação para determinar se o sistema atende as necessidades e requisitos dos usuários
“Você construiu o sistema correto?” Testes
Processo de exercitar um sistema ou componente para verificar que este satisfaz as especificações e para identificar falhas.
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Análise estática e análise dinâmica Estática
Compreende métodos usados para determinar ou estimar qualidade de software, que não envolvem a execução do produto.
Dinâmica Compreende métodos que envolvem execução do produto,
com dados reais e ambiente real ou simulado.
Conceitos Básicos
Inspeçãode Código Análise Estática
Síntese deEntrada
Procedimentosde Testes
TestesAutomatizados
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Conceitos Básicos
Retorno de Investimento (RDI ou ROI – returnon investment) Comparação entre o valor de fazer e o custo de
fazer Mitigação x Contingência
Mitigar: atuar para prevenir a ocorrência do fato Contigenciar: atuar após o fato para minimizar
perdas Regra do Pareto
20% valem por 80%
O Negócio da Verificação e Validação
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
O Negócio da V&V
Breve histórico Princípios Objetivos Aspectos econômicos Valor de negócio
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Breve Histórico
As fases Até 1956 – Orientada a depuração
Não existia diferença entre depuração e testes
1957-1978 – Orientada a demonstrações Foco era mostrar o comportamento esperado
1979-1982 – Orientada a “destruição” Foco era achar problemas
1983-1987 – Orientada a avaliação Foco no processo e em garantia de qualidade
1988-2000 – Orientada a prevenção Foco em detectar e prevenir problemas
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Breve Histórico
Em qual fase está você ou sua empresa? Será que estamos na fase máxima,
“PREVENÇÃO”? Podemos ser mais MODERNOS do que prevenir
problemas? 2000-atual – Fusão
Foco em fundir os processos de desenvolvimento e testes
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Breve histórico
Bug do ano 2000 (Y2K Bug) Testes começaram a ser levados a sério por conta da
ameaça do Y2K Sistemas legados imensos e responsáveis por
processos vitais para o negócio das corporações Como garantir que após as correções de datas, tudo
ficaria funcionando corretamente? Vocês sabem do bug do ano 2064?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Objetivos Principais
Objetivo #1: Identificar a magnitude e origem dos riscos associados ao desenvolvimento de software, minimizáveis por testes Risco são identificados para todo tipo de projeto Avaliação de riscos determina a aposta em um projeto Planejamento de testes pode tornar um projeto viável Testes podem mitigar riscos, não contigenciar!
Testes não podem minimizar o impacto de riscos externos, desconhecidos ou “qualitativos”
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Objetivos Principais
Objetivo #2: Executar testes para reduzir riscos identificados Testes positivos
Buscam cenários que funcionam como esperado Fluxos principais e alternativos!
Testes negativos Buscam cenários que quebram o software
Esforço planejado para testes Maximiza a redução de riscos Combinação de testes positivos e negativos 100% de testes é irreal (Pareto)
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Objetivos Principais
Objetivo #3: Determinar quando os testes estão completos Nem 8 nem 80!
Poucos testes causam incerteza Testes demasiados custam mais caro
Testes positivos são os prioritários Envolvem o teste dos requisitos do projeto Mínimo para garantir o controle de risco do projeto
Testes negativos em seqüência De acordo com a priorização
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Objetivos Principais
Objetivo #4: Gerenciar testes assim como qualquer outra disciplina de Engenharia de Software Planejar, acompanhar, formar equipe, gerir recursos,
inovar Também para testes, porquê não? Existem riscos envolvidos!
Testadores são escassos Assim como desenvolvedores Alocação de recursos de testes deve ser gerida com mesmo
importância dos recursos de desenvolvimento
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Break!
Qual a proporção de testes em seus projetos? Exercício rápido (Exercício 1)
Dois autores Fred Brooks
“The Mytical Man-Month”, de 1975 Trabalhou na IBM, no desenvolvimento do OS/360
Scott Berkun “The Art of Project Management”, de 2005 Trabalhou na Microsoft, no desenvolvimento de Windows, MSN
e Internet Explorer
Qual a proporção que eles sugerem?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Break!
Fred Brooks (IBM / 1975) 1/3 de planejamento 1/6 de codificação 1/4 de testes individuais 1/4 de testes de integração
Scott Berkun (MS / 2005) 1/3 de projeto e gerenciamento 1/3 de implementação 1/3 de testes
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Princípios
Lista elaborada por Everett & McLeod Jr. Existem dezenas de “lista dos 10 príncipios de testes” Essa é mais voltada para uma visão estratégica de
testes Princípios
#1 Riscos de negócio podem ser reduzidos com testes #2 Testes positivos e negativos contribuem com a
redução de riscos Positivo: comportamento p/ entradas válidas Negativo: comportamento p/ entradas inválidas
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Princípios
Princípios #3 “Testes estáticos” contribuem com testes
Teste estático = Revisão Técnica! Se o requisito está errado, não tem a mínima chance do
sistema ser VALIDADO.
#4 Ferramentas de testes automatizados podem contribuir com redução de riscos Talvez seja melhor dizer que a CULTURA de testes
automatizados
#5 Faça com que os mais altos riscos sejam a primeira prioridade de testes
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Princípios
Princípios #6 Faça com que os cenários de negócio mais
freqüentes sejam a segunda prioridade de testes RUP vs. Desenvolvimento Ágil RUP: atacar primeiro os maiores riscos Ágil: atacar primeiro o que agrega mais valor
#7 Análise estatística de padrões e características de defeitos pode ajudar na estimativa do esforço de teste Número de problemas versus tamanho e característica do
projeto
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Princípios
Princípios #8 Realize os testes do sistema da mesma forma
como o usuários irão usá-lo Ambiente de testes o mais próximo do real Ex.: Telefonia Celular (Gaiola de Faraday)
#9 Assuma que defeitos são resultado de um processo, e não da personalidade dos envolvidos O bug é da equipe, da empresa. Não é da pessoa.
#10 Realizar teste para identificar defeitos é um investimento assim com um custo
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
“Testar é caro” Comparado com o quê?
Qual é o custo de NÃO testar? Incerteza sobre cobertura (fiz tudo?) Incerteza sobre qualidade (o que fiz está correto?)
Qual é o custo de encontrar falhas posteriormente? Desgaste do relacionamento com clientes Má impressão dos usuários Remontagem do time de projeto
Aspectos Econômicos
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Aspectos Econômicos
Software falho custa mais para usar Usuários terão dificuldade de entendimento
(comportamento inconsistente) Usuários cometeram mais erros
Software falho diminui motivação Moral é atingida Produtividade piora Melhor para o time é receber feedback prontamente, e
não de forma tardia!
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Aspectos Econômicos
Vamos fazer contas Um erro foi encontrado por um usuário no ambiente de
produção. Então, qual é o caminho a ser feito para corrigir o problema e
disponibilizar uma nova versão do sistema? Passos:
Usuário entra em contato (fone, email, carta, fax, tíquete aberto em sistema de solicitações, etc) e informa o erro.
Analista reproduz o erro no ambiente de produção, e informa equipe de desenvolvimento.
Desenvolvedor reproduz o erro e encontra a falha. Desenvolvedor corrige a falha (em geral a parte mais rápida). Equipe de desenvolvimento disponibiliza nova versão do sistema. Versão do sistema em produção é trocada. Usuário consegue utilizar a funcionalidade corretamente agora... ... mas então detecta outro problema!
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Aspectos Econômicos
Sua organização contabiliza esses aspectos? Qual é o custo de
encontrar falhas posteriormente?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Valor de Negócio
O que é “negócio”? Sistemas existem para dar suporte a processos de negócio
Comerciais, financeiros, entretenimento, pesquisa, etc
Além do sistema em si, outros aspectos podem agregar valor: Documentação, conhecimento adquirido durante o
desenvolvimento E um bom planejamento de testes!
Valor dos testes Diminuir custos de manutenção Documentação baixo nível do sistema Mitigar incertezas Diminuir custos de atualização
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Valor de Negócio
Maximizar valor de negócio Testes podem (e devem) ser organizados para
maximizar valor Alinhamento com missão do projeto Em geral, fala-se apenas de requisitos, arquitetura,
componentes. “20% das funcionalidades agregam 80% de valor”
Por quê não testes? “20% dos testes agregam 80% do valor”
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Valor de Negócio
Exercício 2 Distribuir orçamento de testes em projetos Fichas
Para cada projeto, distribuir 10 fichas entre opções de testes Opções: Usabilidade, Funcionais, Automatizados, Revisão
técnica
Projetos Projeto #1: POS para Operadora de Cartão de Crédito Projeto #2: Aplicação de IM para Dispositivos Móveis
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Valor de Negócio
Exercício 2
Projeto #1 POS p/ Cartão de Crédito Nova arquitetura Diferentes fornecedores de
hardware Camada de aplicação deve
ser única Mecanismo de atualização
automática irá economizar manutenção
Projeto #2 IM para Celular Fácil de usar Multi-protocolo (MSN, GTalk,
ICQ, ...) Baixo consumo de dados Aplicação de referência para
comunidade
Modelo em V
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Modelo em V
Análise de Requisitos
Projeto do Sistema
Projeto da Arquitetura
Projeto dos Módulos
Construção
Teste de Unidade
Teste de Aceitação
Teste Sistêmico
Teste de Componente
Validação
Verificação
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Modelo em V
Análise de Requisitos
Projeto do Sistema
Projeto da Arquitetura
Projeto dos Módulos
Construção
Projeto do Testede Unidade
Projeto do Testede Integração
Projeto do TesteSistêmico
Projeto do Testede Aceitação
Projeto Prematuro de Testes!
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Modelo em V
Projeto prematuro dos testes Ao projetar testes, problemas são encontrados Problemas encontrados cedo são mais baratos de
corrigir Problemas mais significativos são encontrados
primeiro Então que tal verificar logo?
Não há trabalho adicional Simplesmente re-agende o projeto de testes
Projeto de testes pode impactar os requisitos!
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Modelo em V
Análise de Requisitos
Projeto do Sistema
Projeto da Arquitetura
Projeto dos Módulos
Construção
Teste de Unidade
Teste de Aceitação
Teste Sistêmico
Teste de Componente
Revisão Técnica
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Modelo em V
Análise de Requisitos
Projeto do Sistema
Projeto da Arquitetura
Projeto dos Módulos
Construção
Teste de Unidade
Teste de Aceitação
Teste Sistêmico
Teste de Componente
Projeto do Testede Unidade
Projeto do Testede Integração
Projeto do TesteSistêmico
Projeto do Testede Aceitação
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Conceitos Básicos
Verificação Processo de avaliação de um sistema ou componente para
determinar se os artefatos produzidos satisfazem às especificações determinadas no início da fase.
“Você construiu corretamente?” Validação
Processo de avaliação para determinar se o sistema atende as necessidades e requisitos dos usuários
“Você construiu o sistema correto?” Testes
Processo de exercitar um sistema ou componente para verificar que este satisfaz as especificações e para identificar falhas.
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Modelo em V
Verificação, Validação e Testes Níveis
QualquerFase
Testes
Validação
Verificação
Análise de Requisitos
Projeto do Sistema
Projeto da Arquitetura
Projeto dos Módulos
Construção
Teste de Unidade
Teste de Aceitação
Teste Sistêmico
Teste de Componente
Projeto do Testede Unidade
Projeto do Testede Integração
Projeto do TesteSistêmico
Projeto do Testede Aceitação
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Exercício 3
Como você testaria essa especificação? Um programa de computador joga xadrex com um
usuário. É exibido o tabuleiro e as peças na tela. Movimentos são feitos arrastando as peças.
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Exercício 3
Quão influencido pelo seu conhecimento prévio em xadrex foi seu teste?
Planejamento de Alto Nível
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Planejamento Alto Nível
Antes de planejar Defina a estratégia de teste da organização (ou do
negócio) Identifique pessoas a serem envolvidas
(patrocinadores, testadores, desenvolvimento, QA, suporte, etc)
Examine os requisitos e/ou especificações funcionais São os mais básicos artefatos de entrada para os testes
Estabeleça a organização e infra-estrutura do ambiente de testes
Defina quais serão os entregáveis e a estrutura dos relatórios
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Planejamento de Alto Nível
Propósitos de um plano de testes alto nível Servir como meio de comunicação entre todas as
pessoas interessadas (stakeholders) Cliente, gerente de projeto, testadores, desenvolvedores, etc.
Ser personalizado para cada projeto Nenhum projeto é igual a outro!
Demonstrar a viabilidade das estratégias de testes estabelecidas
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Planejamento de Alto Nível
Plano de testes (1 de 5) 1. Identificador do Plano de Testes 2. Introdução
Itens de software e funcionalidades a serem testadas Referências a plano de projeto, plano de QA, políticas e
padrões organizacionais, plano de configuração 3. Itens de teste
Listagem de itens de teste (versões ou revisões de sistemas, fases de desenvolvimento)
Como o sistema chega aos testadores (DVD, Internet, Intranet, VPN, ...)
Referências a documentação ou outros tipos de materiais de apoio
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Planejamento de Alto Nível
Plano de Testes (2 de 5) 4. Escopo
Identificar especificações funcionais 5. Não escopo
Razões para exclusão 6. Abordagem
Técnicas e ferramentas Com detalhamento suficiente para permitir estimativa
Identificar grau de cobertura e outros critérios Exemplo: percentual de falhas permitidas, percentual de testes
executados, priorização em relação ao tempo disponível Identificar restrições
Ambiente, recursos humanos, prazos
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Planejamento de Alto Nível
Plano de Testes (3 de 5) 7. Critérios de execução
Definição de “sucesso” Definição de “falha”
Categorização de criticidade de falhas
8. Critérios de interrupção e continuação Interrupção: caso a condição seja satisfeita, os testes (ou parte
deles) devem ser interrompidos Continuação: sanada a condição de interrupção, quais
atividades precisam ser re-feitas antes de retomar as atividades interrompidas.
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Planejamento de Alto Nível
Plano de Testes (4 de 5) 9. Entregáveis
Plano de Testes (o próprio) Especificações de testes
Validação de arquitetura Projeto de testes de integração Caso de testes funcionais Código-fonte de testes automatizados
Relatórios Análise de arquitetura Resultado de testes de integração Resultado de testes funcionais Resultado de testes automatizados Resultado de testes de aceitação
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Planejamento de Alto Nível
Plano de Testes (5 de 5) 10. Plano de Trabalho (WBS)
Tarefas e suas dependências Habilidades específicas, perfis desejados Atenção: não é um cronograma!
11. Ambiente de testes Espaço físico, equipamentos (hardware) Ferramentas de software Manual de uso, orientações de segurança
12. Papéis e responsabilidades Gestão, projeto, especificação, execução, registro, validação,
resolução de problemas, fornecimento de produtos para os testes
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Planejamento de Alto Nível
Outros aspectos de planejamento Equipe e treinamento Cronograma
Gerenciado em ferramenta própria (ex. MS Project) Marcos de testes vinculados ao cronograma do projeto
Riscos e contingências Plano de contingência para riscos identificados
Revisão Técnica
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica
Requisitos Visão técnica, estória de usuário, requisitos funcionais,
não-funcionais, casos de uso Arquitetura Inspeção de Código
Análise Automatizada de Código Técnicas
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica
Objetivo Prevenir defeitos no produto final.
Porquê? É mais barato investir na prevenção e detecção do que na
remoção Removem defeitos do produto em todo o ciclo de vida
Combinação poderosa: ciclos curtos + revisão técnica Testes e revisões são complementares Problemas facilmente detectáveis por inspeção visual podem exigir a
cobertura completa de todos os cenários de execução no testes
Como? Encontrando defeitos em produtos intermediários
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Requisitos
Sessões JAD – Joint Application Design Criada nos anos 70 na IBM É um processo usado para identificar/coletar requisitos
de negócio no contexto de novos sistemas de informação
Participantes = pessoas interessadas = stakeholders Idéia básica: juntar todos os interessados no novo sistema para
discutir o que é esperado Do cliente: patrocinador e usuários Do fornecedor: facilitadores, escribas e observadores
Pode durar vários dias, e tem por natureza ser uma experiência intensa
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Requisitos
JAD - visão geral
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Requisitos
Passos Identificar objetivo e limitações Identificar fatores de sucesso Definir entregáveis do projeto Definir cronograma das sessões JAD Selecionar participantes Preparar o material das sessões
Projeto preliminar (começar do zero é custoso) Facilitar as atividades e exercícios
Decidir qual o nível de detalhamento e que tipos de modelagens serão usadas
Participantes precisam compreender diagramas e modelos Ações para “abrir” o escopo Ações para “detalhar” o escopo
Registro das discussões (escriba)
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Requisitos
Vantagem Envolvimento forte dos principais interessados no
início do projeto Construção compartilhada gera comprometimento
Desvantagem Muito caro!? Depende...
Quão importante é envolver os principais interessados logo no início do projeto?
Se forem muito interessados, JAD pode se tornar muito complexo para coordenar
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Requisitos
Cuidado! JAD foi criada para grandes sistemas, mas não é
efetiva para projeto de larga escala! Se o projeto é de larga escala, JAD não será a
bala de prata... ... mas vai ajudar a clarear bastante o escopo, as
restrições e os envolvidos com poder de decisão!
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Requisitos
Workshop de Requisitos Apresentação do escopo e não-escopo do projeto para
interessados Trabalho preliminar de modelagem das necessidades
Requisitos Caso de uso Escopo negativo Restrições Premissas
Técnica barata, e pode ser realizada em vários ciclos Gera comprometimento dos participantes da reunião
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Arquitetura
Arquitetura é importante Então deve ser analisada
Arquitetura pode ser receitada Decisões deveriam ser analisadas
Arquitetura é central para comunicação Então deve ser documentada
Arquitetura é caro de se mudar É mais barato analisar cedo
Arquitetura afeta o projeto inteiro Pessoas interessadas precisam ser envolvidas
Requisitos podem ser elicidados cedo Arquitetura precisa ser desenhada alinhada com estes
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Arquitetura
Avaliação de Arquitetura Exemplo: ATAM
Architecture Tradeoff Analysis Method Método de Análise de Custo/Benefício de Arquitetura Desenvolvido pelo SEI – Software Engineering
Institute
Cenários de Negócio
Arquitetura Inicial
Atende?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Arquitetura
Objetivo: Avaliar as conseqüências de decisões arquiteturais na
visão de requisitos/atributos de qualidade Encaixa bem como atividade de uma JAD
Fundamentalmente um mecanismo de identificação de riscos Não garante que a qualidade será alcançada
Custos Pessoal bem qualificado Atrasa o início do projeto Força o desenho top-down da arquitetura
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Break!!!
Qual o perfil de um time? Porque ficam dizendo que os desenvolvedores fazem coisas
erradas? Time de Projeto (por Paulo Vasconcellos)
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Arquitetura
Benefícios da ATAM Financeira = salva dinheiro! Força preparação, documentação, compreensão Identifica erros na arquitetura antes da fase de A&P Garante que a arquitetura está alinhada com os
cenários de negócio Reduz risco!!!
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Arquitetura
Atributos de Qualidade
Desempenho Disponibilidade Usabilidade Segurança
Manutenabilidade Portabilidade Reusabilidade Testabilidade
Visão do Usuário
Visão do Desenvolvedor
Tempo p/ Mercado Custo/benefício Expectativa de
tempo de vida Mercado alvo Integração com
legados
Visão de Negócios
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Arquitetura
Árvore de Atributos de Qualidade (Utility Tree)
Escalabilidade Segurança UsabilidadeDesempenho
Latência de Dados
Atributos
Refinamento
Cenário
Valores
Entrega de Vídeo em Tempo Real
Prioridade: MédiaCusto: Alto
Risco: Médio
Vazão deTransações Confidencialidade
1-Click Buy(Amazon.com)
?
Prioridade: AltaCusto: ?Risco: ?
99,99% das transações
seguras
Prioridade: AltaCusto: ?Risco: ?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Arquitetura
ATAM Utility Tree facilita tomada de decisão Foca em priorização e identificação de riscos
Outra abordagem = SAAM Software Architecture Analysis Method Também desenvolvido pelo SEI Foca em identificar impacto da arquitetura nos
requisitos Direto = Requisitos completamente cobertos Indireto = Requisitos precisam ser alterados
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Código
Análise estática de código PMD, FindBugs, FxCop
Grande base de anti-padrões Personalizáveis: crie suas próprias regras para padrões
próprios
Inspeção manual Inspeção Walkthrough (“Passagem Geral”) Revisão por Par
O que procurar?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Código
InspeçãoPreparação
- Verificar critérios de entrada- Agendar reunião inicial
Introdução
- Apresentar artefatos (autor)- Apresenta objetivos (moderador)- Agendar reunião de inspeção
Reunião deInspeção
- Artefatos são discutidos- Defeitos são registrados- Investigações são registradas- Moderador administra tempo e conflitos
- Artefatos são revisados por cada revisor
Retrabalho
- Autor corrige os defeitos- Investigações são validadas ou rejeitadas
Moderação
- Moderador verifica correção dos defeitos- Moderador verifica critérios de saída
Conclusão
- Pronto!- É possível melhorar o processo de inspeção?
- Defeitos persistem, ou novos foram encontrados
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Código
Inspeção
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Código
WalkthroughPreparação
- Convidar revisor(es)- Agendar reunião
- Apresentar artefato (autor)- Interromper para dúvidas (revisores)- Autor registra defeitos e investigações
Reunião deApresentação
Retrabalho
- Autor corrige os defeitos- Investigações são validadas ou rejeitadas
Moderação
- Moderador verifica correção dos defeitos
Conclusão
- Pronto!
- Defeitos persistem, ou novos foram encontrados
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica - Código
Walkthrough
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica – Código
Revisão por Par Dois envolvidos somente:
Autor e Revisor Processo simples:
1 – Autor prepara artefato e envia para Revisor 2 – Revisor realiza revisão invidualmente 3 – Revisor registra problemas
Email, ferramenta própria, post-it, ... 4 – Autor corrige problemas 5 – Revisor verifica correções 6 – Pronto!
E se... autor e revisor discordarem? Bom, deve ter um líder ou gerente nesse projeto, ok? Não tem mágica, escala o conflito (assim como qualquer outro)
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Revisão Técnica – Código
O que procurar? Primeiro, fundamental, INDISPENSÁVEL
E óbvio... O código executa corretamente os fluxos básicos associados?
Segundo, fundamental, INDISPENSÁVEL E óbvio O código executa corretamente os fluxos alternativos associados?
Outros aspectos Cumpre padrões de arquitetura (e.g. MVC)? Trechos complexos estão comentados? (análise estática ajuda aqui) Testes unitários estão feitos? Documentação/legibilidade estão boas? Tratamento de erros foi realizado corretamente? ...
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Break!
Tipos de Teste
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de componentes (unitários!) Testes de integração Testes sistêmicos
Funcionais Não funcionais
Tipos de Teste
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
Baixo nível Feito por programadores Mais foco nos detalhes
Tratamento de erros Completude e corretude de interfaces
Níveis Módulos Componentes Classes\arquivos
Todos são “testes de unidade” E não precisam ser automatizados!
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
Processo de testes de componentes ou “Testes de
Unidade” Ou “Testes
Unitários”
Teste de Componente
Planejamento
Especificação
Execução
Registro
Verificação de Completude
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
Planejamento Como a estratégia e projeto
de testes se aplica ao componente a ser testado?
Identificar outros componentes de software que estarão interagindo com o componente alvo (stubs, mock, drivers, legados, etc)
Teste de Componente
Planejamento
Especificação
Execução
Registro
Verificação de Completude
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
BREAK!
Mocks, stubs... Qual a diferença? Mock
Mock objects são objetos que simulam o comportamento de objetos reais de forma controlada. São normalmente criados para testar o comportamento de outro objeto.
Stub Um método stub (ou stub) é um trecho de código usado para
substituir alguma funcionalidade do programa. Um stub pode simular o comportamento de código existente (remoto) ou ser um substituto temporário para um código a ser desenvolvido.
Driver Aplicação que injeta dados ou eventos em uma interface (API).
Usado para substituir componentes “usuários”.
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
Especificação Caso de teste
Objetivo Estado inicial (importante!) Entrada Resultado esperado
Testes precisam ser repetíveis
Disciplina para especificar testes até para “bobeirinhas”
Teste de Componente
Planejamento
Especificação
Execução
Registro
Verificação de Completude
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente - Técnicas
Técnicas de projeto de testes Análise de valor de fronteira
Se o programa aceita valores de 0 a 5, o que se deve testar? Que tal: -100, -2, -1, 0, 1, 2, 3, 4, 5, 6, 13, 190?
Outro exemplo:
... -2 -1 0 1 .............. 12 13 14 15 .....--------------- | ----------------- | ---------------------
partição inválida 1 partição válida partição inválida 2
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente - Técnicas
Teste “Caixa Branca” Baseado no código fonte
Foco nos caminhos lógicos Perfis envolvidos
Programador Testador (olhar além do horizonte)
Lembrando... Teste positivo = cenário de uso normal Teste negativo = cenário de uso incorreto Aqui os “usuários” considerados podem ser os próprios
programadores! Como o código está disponível, vale a pena tentar testar cada
linha? 100% de cobertura é impraticável Custo/benefício não compensa (lembram do Pareto?)
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente - Técnicas
Teste “Caixa Preta” Baseado no executável do sistema/componente
Foco no comportamento externo
Perfis envolvidos Desenvolvedor Testador Usuário (olhar além do horizonte... do domínio!)
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente - Técnicas
Exercício 4 Teste mínimo para essa assinatura:
/** Armazena Nome e Email do Cliente.* @param nome Nome do cliente, com 50 caracteres no máximo* @param email Email do cliente* /public void guardaDadosCliente (String nome, String email) throws
CampoInvalidoException;
Nome
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente - Técnicas
Técnicas de projeto de teste Análise de valor de fronteira para BD
Preenchimento de valores dentro e fora da fronteira dos campos
Também é possível stressar as cardinalidades 0..1, 0..n, 1..n, n..m, 1..1
Prepare massa de testes com todas as combinações possíveis Recomendável se é realizada carga de dados de um sistema
para outro
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente - Técnicas
Técnica de projetos de testes Análise de diagrama de estados Exercício 5:
testar estado “PumpOn”
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
Execução Casos de testes são
executados Manuais ou automatizados Automatizados é melhor,
mas não ter ambiente não édesculpa para não preparar testes unitários!
Testes unitários pode ser manual, porquê não?
Teste de Componente
Planejamento
Especificação
Execução
Registro
Verificação de Completude
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
Integração Contínua Ambiente automatizado para
Compilação Análise de código Execução de testes unitários Análise de cobertura de execução
Integrado ao controle de versão Freqüência configurada
A cada atualização do código Uma vez a cada “X” horas ou uma vez por dia
Exemplos Cruise Control Luntbuild
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
Conbinando IC e Testes Unitários Time deve levar a sério o conceito de “erro zero”
Se relaxar, em pouco tempo os testes estarão todos falhos Interface do ambiente deve ser fácil
Quebrou? Mostrar erro de forma bem visível. Avisar ao time (email, MSN, GTalk, Twitter?) Relatórios devem ser limpos
Ambiente tem que estar disponível sempre que tiver alguém trabalhando De manhã cedo, tarde da noite, sábado e domingo
Execução de testes unitários disponível no ambiente de cada desenvolvedor
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
Registro Identificação dos
componentes testados e versões
Resultados gerados, comparado com resultados esperados
Falhas/erros são registrados e informados
Repetir fases anteriores Verificar critérios de
cobertura do projeto Ex.: 80% de cobertura de
testes, 100% dos testes executados corretamente.
Teste de Componente
Planejamento
Especificação
Execução
Registro
Verificação de Completude
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
Testes unitários Criação
Fluxos principais, alternativos Análise de valor de fronteira Mocks, stubs, etc...
Melhoria contínua Escapou alguma coisa dos testes unitários? Dá para escrever um teste unitário que ressalte o problema? Escreva antes o teste unitário, depois corrija o problema
Test-driven bug fixing! Exemplo: quantos pontos posso ter em um endereço de email?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Componente
Verificação de completude Avaliação dos resultados
comparados com os critérios de completude
Se não atingir... re-análise se é preciso mais antes de re-fazer
Pode ser necessário repassar pelo planejamento ou especificação
Teste de Componente
Planejamento
Especificação
Execução
Registro
Verificação de Completude
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de componentes Testes de integração Testes sistêmicos
Funcionais Não funcionais
Tipos de Teste
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
Importante em sistema modularizados Os módulos funcionam corretamente... juntos?
Foco Comunicação entre componentes O quê o conjunto pode fazer que não é possível individualmente
... mas que foi antecipado com o mocks, certo? Aspectos não funcionais podem começar a entrar na jogada
Estratégia Big-Bang ou Incremental
Planejamento da integração está intimamente atrelado ao desenho da arquitetura e das fases do projeto
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
Big-Bang Na teoria
Se eu já testei meus componentes isoladamente, porque eu não junto tudo de uma só vez? Vou ganhar tempo!
Onde está o erro aqui? Assumiu que não existem defeitos...
Na prática Fica difícil isolar defeitos (qual componente falhou?) Fica difícil re-testar após correções No final, leva mais tempo
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
Incremental Componentes são combinados aos poucos Baseline 1: Componente A Baseline 2: Componente A e C Baseline 3: Componente A, B e C
Vantagens Mais fácil isolar problemas Mocks (você fez, correto?) são removidos ao longo da
integração Mais fácil re-testar correções
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
Integração Top-down Quem é o “top”?
Quais as opções de integração?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
Vantagens da top-down Componente de controle (em geral mais críticos), são
testados em primeiro lugar Possibilidade de demonstrar o sistema mais cedo
Validação, lembram?
Desvantagens Mocks são essenciais Detalhes dos componentes “de baixo” são deixados
por último São críticos? Então, mude a estratégia
Pode parecer terminado, mas não está
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
Integração Bottom-up
Quais as opções de integração?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
Vantagens bottom-up Componentes de níveis mais baixos testados primeiro
Segurança de estar construindo bases corretas... ... ou não, pois ainda é preciso VALIDAR!
Bom para testar interfaces com recursos externas ao ambiente Hardware, rede, serviços online
Desvantagens Não temos sistema funcional até uma baseline com
componentes “top” Preciso de mocks e drivers também Validação de componentes de controle realizada por último
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
Como várias coisas na vida, adivinha o que pode ser a melhor opção? Mesclar top-down e bottom-up
Integração Capacidade Mínima
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de Integração
Vantagens capacidade mínima Componentes de controle testados em primeiro lugar Componentes de baixo nível importantes testados em
primeiro lugar Sistema parcial realmente funcional
Desvantagens Pode precisar de drivers se não for feito top-down Precisa de mocks e drivers dependendo da topologia
do sistema Mocks precisam ser mais “espertos”
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Teste de componentes Testes de integração Testes sistêmicos
Funcionais Não funcionais
Tipos de Teste
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Testes Sistêmicos - Funcionais
Testes projetados de acordo com a documentação de cenários de uso existente Casos de uso Estórias de usuário (métodos ágeis)
Executado por grupo independente! Primeiro passo
Rascunhar um caso de teste para os cenário principal e alternativos Segundo passo
Inserir detalhes como intervalos, regras de negócio, valores de validação Na hora de rodar
Primeiro executar testes para partes mais específicas, atômicas Depois focar nos testes de cenários completos Ajuda a isolar problemas
Eficiência nas correções de defeitos
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Break!
“Causo” sobre teste de software Relatado pelo Prof. José Augusto Fabri http://engenhariasoftware.wordpress.com
Vamos a história... http://engenhariasoftware.wordpress.com/2008/09/23/u
m-pouco-de-teste-de-software/
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Testes Sistêmicos
Tentem a próxima coisa! Quando estiver testando, não pare, não retorne ao
começo... ... faça o que o usuário fará em seguida.
Exemplo: Tela de modificação de senhas
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Testes Sistêmicos
Não Funcionais Desempenho
Grande massa de dados ou usuários Picos de utilização ou acesso Famoso “Teste de Carga”
Robustez Sistema não para de funcionar ao longo do tempo Ex.: impressoras fiscais, sites de comércio eletrônico, controle de
radar aéreo Segurança
Importante para sistemas com dados sensíveis Não envolve só infra-estrutura Ethical hacking
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Testes Sistêmicos
Não Funcionais Usabilidade
Verifica se interface é fácil de usar e intuitiva Quase sempre subjetivo, por isso deve envolver o usuário sempre
que possível Pode ser objetivo também:
Exemplo: 1-buy click da Amazon Navegação por teclado Lei de acessabilidade
Internacionalização Sistema precisa trabalhar com múltiplas línguas Vai testar só com o português ou inglês? Os textos traduzidos cabem nos espaços da interface?
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Testes Sistêmicos - Priorização
Está acabando o tempo, o que priorizo? Testes positivos
Verifique até onde já foram realizados os testes Do que sobrou, o que agrega mais ao cliente? Testes positivos abragem as funcionalidades que mais agregam
ao cliente Testes de defeitos escondidos
Verifique até onde já foram realizados os testes Qual o tipo de erro mais recorrente? Ataque os erros mais comuns, tanto em desenvolvimento como em
teste Mais pontos de falhas podem ser identificados/corrigidos com
menor esforço
Conclusão
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Conclusão
Testes Definitivamente incorporado a Engenharia de Software A vitória do pragmatismo sobre o heroísmo
Nada de glamour aqui. É negócio, gestão de riscos! “Desenvolvedores” vs. “Testadores”
Um não vive sem o outro em um ambiente de desenvolvimento profissional
Métodos ágeis Está fundindo os papéis Métodos e ferramentas para elaborar testes antes do
desenvolvimento TDD – Test-driven Development (JUnit) BDD – Behavior-driven Development (Cucumber)
Não “joga fora” os conceitos Apenas passa por todos eles de forma muito rápida, e às vezes
imperceptível
Trabalho da Disciplina
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Pós-aula
Grupo de discussão Acompanhamento dos trabalhos Troca de materiais http://groups.google.com.br/group/inta_es_2008_1
Enviar formação das equipes por email para receber o edital do trabalho.
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Trabalho da Disciplina
Contexto Sua empresa ganhou a concorrência de uma licitação Sua equipe é responsável pela área de testes, vocês precisam
“vender” o seu trabalho Problema: apenas 30% do orçamento será destinado a testes
Objetivo Elaborar um Plano de Testes para o projeto Plano alinhado com os requisitos funcionais, não-funcionais e de
negócio Plano deve mostrar quais aspectos são prioritários
Critérios de avaliação Consistência do plano como um todo Consistência com as informações do edital (importante!!!) Formato (.doc ou .pdf) e apresentação
Faculdades INTA – Junho/2009 Engenharia de Software – Verificação, Validação e Testes de Software
Trabalho da Disciplina
Data de entrega Entrega: 17 de julho, até 23:59h (Horário de Brasília) Divulgação de resultados: 24 de julho
Atendimento para dúvidas Por email: [email protected] Dúvidas de interesse do grupo serão respondidas
com cópia ao grupo Dúvidas somente até o dia 09 de Julho
Obrigado!