Testes de Software: Conceitos, Planejamento e Tipos

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

Pós-Graduação em Engenharia de Software
Prof. Camilo Almendra, MsC.

Junho/2009

Agenda

 Conceitos básicos
 O Negócio da V&V
 Modelo em V
 Planejamento
 Revisão técnica
 Tipos de testes
 Trabalho Final

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

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


Conceitos Básicos

 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.
Inspeção
Análise Estática
de Código

 Dinâmica
 Compreende métodos que envolvem execução do produto,
com dados reais e ambiente real ou simulado.

Síntese de Procedimentos Testes
Entrada de Testes Automatizados


Conceitos Básicos

 Retorno de Investimento (RDI ou ROI – return
on 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


Aspectos Econômicos

 “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



 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  Projeto #2
 POS p/ Cartão de Crédito  IM para Celular
 Nova arquitetura  Fácil de usar
 Diferentes fornecedores de  Multi-protocolo (MSN, GTalk,
hardware ICQ, ...)
 Camada de aplicação deve  Baixo consumo de dados
ser única  Aplicação de referência para
 Mecanismo de atualização comunidade
automática irá economizar
manutenção


Modelo em V

Análise de
Requisitos
Validação Teste de
Aceitação

Projeto do Verificação Teste
Sistema Sistêmico

Projeto da Teste de
Arquitetura Componente

Projeto dos Teste de
Módulos Unidade

Construção


Modelo em V

Projeto Prematuro
de Testes!

Projeto do Teste
de Aceitação
Análise de
Requisitos

Projeto do Teste
Sistêmico
Projeto do
Sistema

Projeto do Teste
de Integração
Projeto da
Arquitetura
Projeto do Teste
de Unidade

Projeto dos
Módulos

Construção


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

Análise de Teste de
Requisitos Aceitação

Projeto do Revisão Técnica Teste
Sistema Sistêmico

Projeto da Teste de

Módulos Unidade

Construção


Modelo em V

Projeto do Teste
de Aceitação

Projeto do Teste
Sistêmico
Projeto do Teste
Sistema Sistêmico

Projeto do Teste
de Integração
Projeto da Teste de
Projeto do Teste
de Unidade

Módulos Unidade

Construção


Modelo em V

 Verificação, Validação e Testes
 Níveis
Projeto do Teste
de Aceitação

Projeto do Teste
Sistêmico
Projeto do Teste
Sistema Sistêmico

Projeto do Teste
de Integração

Projeto da Teste de

Validação

Projeto do Teste
de Unidade

Módulos Unidade

Testes
Construção

Qualquer
Fase

Verificação


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


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



 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



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



 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



 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

 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 Arquitetura
Negócio 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  Tempo p/ Mercado
 Disponibilidade  Custo/benefício
Visão do Usuário
 Usabilidade  Expectativa de
tempo de vida Visão de
 Segurança
 Mercado alvo Negócios
 Integração com
legados
 Manutenabilidade
 Portabilidade Visão do Desenvolvedor
 Reusabilidade
 Testabilidade


 Árvore de Atributos de Qualidade (Utility Tree)

Desempenho Escalabilidade Segurança Usabilidade
Atributos

Latência Vazão de
Confidencialidade ?
de Dados Transações
Refinamento

99,99% das
Entrega de Vídeo 1-Click Buy
Cenário transações
em Tempo Real (Amazon.com)
seguras

Prioridade: Média Prioridade: Alta Prioridade: Alta
Valores Custo: Alto Custo: ? Custo: ?
Risco: Médio Risco: ? 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?


- Artefatos são revisados
por cada revisor
 Inspeção
Reunião de
Preparação Introdução
Inspeção

- Verificar critérios de - Apresentar artefatos (autor) - Artefatos são discutidos
entrada - Apresenta objetivos - Defeitos são registrados
- Agendar reunião inicial (moderador) - Investigações são
- Agendar reunião de inspeção registradas
- Moderador administra
tempo e conflitos

- Defeitos persistem, ou
novos foram encontrados

Conclusão Moderação Retrabalho

- Pronto! - Moderador verifica - Autor corrige os
- É possível melhorar o correção dos defeitos defeitos
processo de inspeção? - Moderador verifica - Investigações são
critérios de saída validadas ou rejeitadas



 Inspeção



 Walkthrough
Reunião de
Preparação
Apresentação

- Convidar revisor(es) - Apresentar artefato (autor)
- Agendar reunião - Interromper para dúvidas
(revisores)
- Autor registra defeitos e
investigações

- Defeitos persistem, ou
novos foram encontrados

Conclusão Moderação Retrabalho

- Pronto! - Moderador verifica - Autor corrige os
correção dos defeitos defeitos
- Investigações são
validadas ou rejeitadas



 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


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
 Classesarquivos
 Todos são “testes de unidade”
 E não precisam ser automatizados!


Teste de Componente

Teste de Componente
 Processo de testes
de componentes
Planejamento
 ou “Testes de
Unidade” Especificação

 Ou “Testes
Unitários” Execução

Registro

Verificação
de Completude


Teste de Componente

Teste de Componente
 Planejamento
 Como a estratégia e projeto
Planejamento
de testes se aplica ao
componente a ser testado?
Especificação  Identificar outros
componentes de software
Execução que estarão interagindo com
o componente alvo (stubs,
Registro mock, drivers, legados, etc)
Verificação
de Completude


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

Teste de Componente
 Especificação
 Caso de teste
 Objetivo
Planejamento
 Estado inicial (importante!)
Especificação
 Entrada
 Resultado esperado
Execução  Testes precisam ser
repetíveis
Registro  Disciplina para especificar
testes até para “bobeirinhas”
Verificação
de Completude


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

Teste de Componente
 Execução
 Casos de testes são
Planejamento
executados
 Manuais ou automatizados
Especificação  Automatizados é melhor,
mas não ter ambiente não é
Execução desculpa para não preparar
testes unitários!
Registro
 Testes unitários pode ser
Verificação manual, porquê não?
de Completude


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
Teste de Componente  Identificação dos
componentes testados e
versões
Planejamento  Resultados gerados,
comparado com resultados
esperados
Especificação
 Falhas/erros são registrados
e informados
Execução  Repetir fases anteriores
 Verificar critérios de
Registro
cobertura do projeto
 Ex.: 80% de cobertura de
testes, 100% dos testes
Verificação executados corretamente.
de Completude


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?
 pt2en@bot.talk.google.com


Teste de Componente

Teste de Componente
 Verificação de completude
 Avaliação dos resultados
Planejamento
comparados com os
critérios de completude
Especificação  Se não atingir...
 re-análise se é preciso mais
Execução  antes de re-fazer
 Pode ser necessário
Registro
repassar pelo planejamento
Verificação
ou especificação
de Completude


Tipos de Teste

 Teste de componentes
 Testes de integração
 Testes sistêmicos
 Funcionais
 Não funcionais


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”


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

 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

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.


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


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: camilo.almendra@gmail.com
 Dúvidas de interesse do grupo serão respondidas
com cópia ao grupo
 Dúvidas somente até o dia 09 de Julho


Testes de Software: Conceitos, Planejamento e Tipos

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Testes de Software: Conceitos, Planejamento e Tipos

Similaire à Testes de Software: Conceitos, Planejamento e Tipos (20)

Plus de Camilo Almendra

Plus de Camilo Almendra (14)

Testes de Software: Conceitos, Planejamento e Tipos