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


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


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)


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.


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


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


O Negócio da V&V

Breve histórico Princípios Objetivos Aspectos econômicos Valor de negócio


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


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


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?


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”



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)



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



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


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?


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


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


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


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


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


“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



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!



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!



Sua organização contabiliza esses aspectos? Qual é o custo de

encontrar falhas posteriormente?


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


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”


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


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


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


Modelo em V


Projeto do Sistema



Construção

Projeto do Testede Unidade

Projeto do Testede Integração

Projeto do TesteSistêmico

Projeto do Testede Aceitação

Projeto Prematuro de Testes!


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!


Modelo em V


Projeto do Sistema



Construção

Teste de Unidade


Teste Sistêmico

Teste de Componente

Revisão Técnica


Modelo em V


Projeto do Sistema



Construção

Teste de Unidade


Teste Sistêmico

Teste de Componente






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.


Modelo em V

Verificação, Validação e Testes Níveis

QualquerFase

Testes

Validação

Verificação


Projeto do Sistema



Construção

Teste de Unidade


Teste Sistêmico

Teste de Componente






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.


Exercício 3

Quão influencido pelo seu conhecimento prévio em xadrex foi seu teste?

Planejamento de Alto Nível


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



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



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



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



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.



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



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



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


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


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


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



JAD - visão geral



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)



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



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!



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


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



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?



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


Break!!!

Qual o perfil de um time? Porque ficam dizendo que os desenvolvedores fazem coisas

erradas? Time de Projeto (por Paulo Vasconcellos)



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!!!



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



Á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: ?



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


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?



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



Inspeção



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



Walkthrough


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)


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? ...


Break!

Tipos de Teste


Teste de componentes (unitários!) Testes de integração Testes sistêmicos

Funcionais Não funcionais

Tipos de Teste


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!


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


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



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”.


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



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



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?)



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!)



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

Email



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



Técnica de projetos de testes Análise de diagrama de estados Exercício 5:

testar estado “PumpOn”


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



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


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


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



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?

[email protected]


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



Teste de componentes Testes de integração Testes sistêmicos


Tipos de Teste


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



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



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



Integração Top-down Quem é o “top”?

Quais as opções 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á



Integração Bottom-up

Quais as opções 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



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



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”


Teste de componentes Testes de integração Testes sistêmicos


Tipos de Teste


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


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/


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


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


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?


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


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


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.



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



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!

Technology

Verificação, Validação e Teste de Software