O documento discute validação e testes de software, abordando tópicos como:
1) Os diferentes níveis de teste (unidade, integração, sistema e aceitação);
2) As abordagens de teste (caixa preta e caixa branca);
3) Os principais papéis no processo de teste (gerente de teste, líder de projeto de teste, etc);
4) A importância da documentação no planejamento e execução dos testes.
11. Regra 10 de Myers
Custo da correção de defeitos: Extraído de Bastos; Rios; Cristalli; Moreira (2007)
12. Redução de defeitos
• Testes unitários podem remover entre 30%
e 50%
• Testes sistêmicos podem remover 30% e
50%
• Revisões de códigos podem reduzir entre
20% e 30%
• Mesmo assim, os sistemas podem ir para a
produção ainda com aprox. 49% de defeitos
Extraído de Bastos; Rios; Cristalli; Moreira (2007)
13. Ciclo de Vida do Software
Um software pode ainda estar rodando
mesmo depois de ter sido construído (10
anos…)
Riscos?
• Falta de profissional especialista na
tecnologia
• Custo de parar o sistema que está rodando
para corrigir um erro
24. Como priorizar? Quais testes são
importantes?
• Analisar os riscos e impactos
– Requisito: tempo de resposta -> Teste de
performance
“É necessário ter uma metodologia
estruturada de teste”
25. Verificação x Validação
• Verificação: realizar inspeções sobre os
artefatos gerados nas etapas do processo
• Validação: Avaliar se o sistema atende aos
requisitos
Definições de verificação e validação. Fonte: Extraído de Bastos, et al (2007)
26. Inspeção de código (verificação)
O time inspeciona os artefatos produzidos à
procura de possíveis erros. Importante existir
um checklist.
Conduzindo por um desenvolvedor que não
seja o autor do código
Ferramentas: PMD e FindBugs
(MYERS, BADGET e SANDLER, 2012)
27. Passo a passo (walkthrough)
Geralmente informal, o autor do código
apresenta o código para o time e o time faz
sugestões.
(MYERS, BADGET e SANDLER, 2012)
29. Conceito “V” de teste
Conceito “V” de teste de software. Fonte: Extraído de Bastos, et al (2007)
30. Passos do Processo de Teste
1. Acesso ao Plano de Desenvolvimento
2. Plano de Testes
3. Avaliação dos Requisitos do Software
4. Avaliação do Desenho
5. Inspeção da Construção do Software
6. Execução dos Testes
1. Abordagem
2. Ferramentas
3. Tipos de Teste
31. Passos do Processo de Teste
7. Teste de Aceitação
8. Informação dos Resultados
1. Bugs
2. Melhorias
9. Teste de Instalação
10. Teste das Mudanças
11. Avaliação da Eficácia
32. Ciclo de vida de testes
1. Planejamento
2. Preparação
3. Procedimentos Iniciais
4. Especificação
5. Execução
6. Entrega
Ciclo de vida de testes: Adaptado de Bastos, et al (2007)
33. Modelo 3P x 3E do Ciclo de Vida
Modelo 3P x 3E. Fonte: Extraído de Bastos, et al (2007)
35. Nível de Teste de Software
• Representa a que fase do desenvolvimento
se aplica um determinado teste.
– Teste de Unidade
– Teste de Integração
– Teste de Sistema (ou sistêmico)
– Teste de Aceitação
36. Teste de Unidade
Estágio mais baixo da escala de teste
Feito pelos desenvolvedores
Testa as classes, métodos, funções,
componentes isolando/simulando suas
dependências
37. Teste de Unidade
//JUnit Example
Discipline discipline = new Discipline();
discipline.setName("Prog 1");
discipline.setWorkload(120);
Assert.assertEquals("Prog 1", discipline.getName());
38. Teste de Unidade
//JUnit Example
Calculator
calculator
=
new
Calculator();
calculator.add(1,
2);
Assert.assertEquals(3,
calculator.getResult());
39. Teste de Integração
Teste do sistema ao término de cada iteração.
Teste da integração entre os componentes.
40. Teste de Integração
//JUnit Example
Discipline discipline = new Discipline();
discipline.setName("Prog 1");
discipline.setWorkload(120);
Assert.assertTrue(disciplineApplication.save(discipline));
41. Teste de Sistema
Teste do sistema como um todo depois da
integração dos componentes.
Utiliza um ambiente parecido ou igual ao
ambiente real
42. Teste de Aceitação
Verificar se o software está pronto para ser
usado.
Verificar o comportamento do software
Feito no ambiente de homologação
44. White box
Se concentra do comportamento do software
sem se deter a sua estrutura interna.
Verifica se o programa se comporta de acordo
com suas especificações.
• Teste Sistêmico
• Teste de Aceitação
(MYERS, BADGET e SANDLER, 2012)
45. Black Box
Testa a estrutura interna, a lógica do
software.
O critério de busca é o Teste do Caminho,
testando os possiveis caminhos que o
software pode tomar.
• Teste unitário
• Teste de Integração
(MYERS, BADGET e SANDLER, 2012)
47. Papeis do Processo de Teste
Papel Responsabilidade
Gerente de Teste Responsável pela área de
teste na empresa
Líder do Projeto de Teste Líder do time de testes
Arquiteto de Teste Montagem de Infra-
estrutura e ambiente,
ferramentas, preparação
do time
Profissionais do processo de teste. Fonte: Adaptado de Bastos, et al (2007)
48. Papeis do Processo de Teste
Papel Responsabilidade
Analista de Teste Elaboração dos casos e
scripts de teste
Testador Execução dos casos de
teste e scripts de teste
Profissionais do processo de teste. Fonte: Adaptado de Bastos, et al (2007)
50. Ambiente
• Toda a estrutura onde os testes serão
executados
– Ambiente físico
– Pessoal
– Hardware
– Software
– Suprimentos
– Rede
– Documentação
51. Ambiente
Ao definirmos o ambiente de teste devemos
considerar:
• OS
• Arquitetura do sistema
• Identificação dos componentes
• Meio de acesso ao sistema
• Linguagem de programação
• Conectividade entre ambientes
(RIOS e MOREIRA, 2003, apud BASTOS el al., 2007)
53. Documentação
• Plano de Testes
– Planejamento para a execução dos testes,
abrangência, abordagem, níveis, ambientes,
recursos e técnicas.
• Especificação de Caso de Teste
– Define os cenários com entradas, saídas,
resultados esperados e condições para a
execução.
54. Plano de Testes
• Descreve quais testes serão executados e
como será feita a execução
– Escopo
– Ambiente
– Abordagem
– Nível
– Técnicas
55. Plano de Testes
– Artefatos liberados
– Responsabilidade
– Cronograma
– Critérios de completude
Requisitos do Projeto à Plano de Testes
58. Procedimentos de Teste
“…os testes devem ser executados em todas
as etapas do ciclo de vida do processo de
desenvolvimento de software, desde os
requisitos até o teste de aceitação, na fase de
homologar e liberar o software para a
produção.”
(BASTOS el al., 2007)
59. Procedimentos de Teste
• Plano de teste sempre atualizado.
• Responsabilidades
Teste Unitários
Feito pelos desenvolvedores
Teste de Integração
Feito quando os componentes a ser
integrados já tiverem seus testes unitários
feitos.
60. Procedimentos de Teste
Teste de Sistema
– Ambiente deve se aproximar do ambiente de
produção
– Definir quais casos de teste serão empregados
nessa fase
– Avaliar os resultados dos testes e identificar
problemas encontrados
– Registro de defeitos
– Garantir que usuários finais não encontrem
erros grosseiros
61. Procedimentos de Teste
Teste de Aceitação
– Realizado pelos usuários do software para
garantir que tudo que foi definido tenha sido de
fato implementado.
62. Procedimentos de Teste
Quando parar de testar?
• Métricas
– Tempo médio entre defeitos encontrados
– Porcentagem de cobertura alcançada
– Número de defeitos encontrados que não
foram corrigidos dependendo do seu grau de
severidade
63. Procedimentos de Teste
Construir
casos de
teste
Executar
os testes
Registrar os
resultados
dos testes
Identificar a
natureza dos
problemas e
retrabalhar o teste
Foram
encontra
dos
defeitos
Os testes
foram
executados
corretame
nte?
Construir
casos de
teste
Ambiente
Plano de
Teste
Softwares
de Teste
Documen
tação
Relatórios
Fluxo de execução dos testes. Fonte: Adaptado de Bastos, et al (2007)
65. Casos de Teste
Detalhamento das interações com a
aplicação. Estabelece quais as informações
empregadas e os resultados.
– Cenários
– Pré-condição
– Pós-condição
– Critério de aceitação
66. Casos de Teste
– Configuração de ambiente
– Manual/Automatizada
– Dependências
Características
– Efetivo
– Econômico
– Reutilizável
– Rastreável
– Auto-explicativo
68. User Story
• Representa uma funcionalidade/
caracteristica do produto narrada pelo
cliente.
• São as necessidades do cliente, mostrando
qual problema ele deseja resolver.
(COHN, 2004)
70. User Story - Exemplo
[US_03] Realizar reserva
Como um usuário do sistema
Eu quero poder realizar a reserva de salas da minha
instituição
Para facilitar o controle de reservas e evitar atrasos
!
71. BDD
Behavior-driven development ou
Desenvolvimento Orientado ao
Comportamento.
Combina ideias do TDD e DDD e Projeto
Orientado a Objeto que fornece ao time um
processo compartilhado para o
desenvolvimento do software
(YE, 2013)
72. BDD
• Linguagem ubiqua
– Linguagem natural
– Linguagem compartilhada
• Foco no Minimum Markatable Feature
• Valor verificável para o negócio
• Requisitos aliado aos testes
• Baseado naquilo que se espera da
aplicação
• Documentação viva
74. BDD
Dado que… (pré-condição)
E… (mais uma pré-condição)
Quando… (ação)
E… (mais uma ação)
Então… (pós-condição)
E… (mais uma pós-condição)
75. Cenário BDD - Exemplo
[US_3] Realizar reserva
Como um usuário do sistema
Eu quero poder realizar a reserva de salas da minha
instituição
Para facilitar o controle de reservas e evitar atrasos
!
76. Cenário BDD - Exemplo
[TC_3.1] Realizar uma reserva com sucesso
Dado que eu estou na tela principal
E seleciono a opção “Resevas”
E preencho o campo “Responsável”
E preencho o campo “Sala”
E seleciono a data
E seleciono a hora
Quando eu clico em “Finalizar”
Então devo ver a mensagem “Reserva realizada com
sucesso”
79. Técnicas de Teste
• Estrutural
– Garantir que o software é sólido. Relacionados
as características do software.
• Funcional
– Garantir que o software atende aos requisitos.
82. Estrutural – Teste de Estresse
Avalia o software sob condições críticas.
• Restrição de Memória
• Processamento
• Armazenamento
• Volume de Dados
• Tempo de Transação
83. Estrutural – Teste de Estresse
Objetivos
• Determinar que a aplicacao suporta volume de
transação normal ou acima do normal num
periodo de tempo esperado
• Determinar que a aplicação suporta volume
normal e continua a funcionar corretamente
Comuns em aplicações web
85. Estrutural – Teste de Execução
Avalia o tempo de resposta, de
processamento e desempenho.
• Tempo de resposta das transações
86. Estrutural – Teste de Execução
Objetivos
• Determinar o tempo de resposta das
transações
• Determinar se hardware e software
fornecem capacidade adequada
• Código é executado com eficácia
88. Estrutural – Teste de Recuperação
• Capacidade de reiniciar operacoes após a
perda de integridade.
• Garantir a continuidade das operações
após um erro.
– Fatores
• Volume de dados processados no momento do erro
89. Estrutural – Teste de Recuperação
Objetivos
– Verifica a eficácia e eficiência o processo de
recuperação
– Backup
– Documentar procedimentos de recuperação
91. Estrutural – Teste de Operação
Objetivos
– Estabelecer se o sistema é executável durante a
operação normal
– Se os utilizadores do sistema conseguem
utilizar-lo, utilizando a documentação
preparada.
– Os utilizadores devem testar sem ajuda
nenhuma
93. Estrutural – Teste de Conformidade
• Verifica se a aplicação foi desenvolvida de
acordo com os padrões de TI
– Aumentar as chances de sucesso
– Transferência de conhecimento e curva de
aprendizado
– Manutenibilidade
94. Estrutural – Teste de Conformidade
Objetivos
– Padrões de TI estão sendo seguidos e de forma
adequada
– Avalidar documentação
– Falta de conformidade foi falta de
comunicação? Problema no processo? Padrões
mal entendidos?
96. Estrutural – Teste de Segurança
• Verificar a confidencialidade das
informações e proteção dos dados contra
acesso indevido.
– Segurança da Informação
– Defeitos difíceis de indentificar
97. Estrutural – Teste de Segurança
Objetivos
– Riscos?
• Determinar as regras de acesso e se foram
implementadas de acordo com as definições
• Verificar se as medidas de segurança foram
corretamente implementadas
– Riscos baixos, tecnicas de invasão usual:
• Pode-se realizar os testes
– Riscos altos, técnicas de invasão sofisticadas:
• Testes conduzidos por pessoal especializado
100. Funcional – Teste de Requisitos
Objetivos
– Verificar se o sistema faz o que está
especificado nos requisitos.
– Verificação do comportamento do sistema
– Checklist de funcionalidades
– Normalmente os testes são preparados na fase
de requisitos
102. Funcional – Teste de Regressão
• Voltar a testar componentes já testados
após implementação de uma mudança em
outra parte do software
Objetivos
– Determinar se a funções previamente testadas
continuam funcionando após a introdução de
mudanças no sistema
103. Funcional – Teste de Regressão
Riscos
– Tempo e custo
• Automação de Testes
Quando usar?
Quando os riscos de mudança do software
são altos
105. Funcional – Teste de Tratamento de Erros
• Verificar a capadicade do sistema de tratar
transações incorretas
Objetivos
– Determinar as condições de erro e tratá-los
– Testar o erro e o acerto
107. Funcional – Teste de Interconexão
• Verificar a conectividade do software com
outros softwares
– Sejam dados recebidos ou fornecidos
Objetivos
– Verificar se os dados são recebidos e/ou
enviados corretamente
– Executar quando as entradas e saídas dos
softwares relacionados mudarem
109. Funcional – Teste Paralelo
• Teste de compatibilidade. Demonstrar
consistência e cincosistências entre
versões do mesmo software
• Mesmos dados de entrada funcionem em
software de diferentes versões
111. Gestão de defeitos
• Prevenção de defeitos
• Baselines
• Identificação
• Registro
• Solução do defeitos
• Melhoria do processo
• Relatório de gestão
(BASTOS et al., 2007)
115. Teste de Unidade
@Test
public void sumTwoNumbers() {
Calculator calculator = new Calculator();
calculator.add(1, 2);
Assert.assertEquals(calculator.getResult(), 3);
}
http://junit.org
116. Teste de Unidade
• Ruby
– Rspec: http://rspec.info
• .Net
– Nunit: http://www.nunit.org
124. CBTS
Certificação Brasileira de Teste de Software
Criada pela ALATS (Associação Latino
Americana de Teste de Software), procura
estabelecer um padrão de conformidade para
avaliação da qualificação dos profissionais da
área da qualidade do software.
125. CBTS
Certificação Brasileira de Teste de Software
Criada pela ALATS (Associação Latino
Americana de Teste de Software), procura
estabelecer um padrão de conformidade para
avaliação da qualificação dos profissionais da
área da qualidade do software.
134. Bibliografia
• BASTOS, Aderson, at al. Base de conhecimento em
teste de software. 2. ed. rev. São Paulo: Martins, 2007.
• MYERS, Glenford J.; BADGET, Tom; SANDLER, Corey.
The art of software testing. 3. ed. Wiley, 2012.
• WATKINS, John. Agile testing: how to succeed an
extreme testing environment. Cambridge, 2009.
• YE, Wayne. Cucumber BDD how-to: A short guide to
mastering behavior-driven software development with
cucumber. Packt Publishing, 2013.
135. Bibliografia
• KEITH, Clinton. Agile game development with
scrum. Addison-Wesley, 2010.
• COHN, Mike. User stories applied: for agile
software development. Addison-Wesley, 2004.