|
1
|
|
|
2
|
- Vinicius Manhaes Teles, Extreme Programming, Novatec Editora
- Agile Software Development
- Scrum and XP from the Trenches
- Martin Fowler, Analysis Patterns - Reusable Object Models,
Addison-Wesley,1997
- Martin Fowler, Refatoração - Aperfeiçoando o projeto de código existente,
Ed Bookman
|
|
3
|
- Modulo I – Xtreme Programming
- Valores e Princípios do XP
- Desenvolvimento centrado em Testes
- Continuous Integration
- JUnit, Maven, Code-cruiser
|
|
4
|
|
|
5
|
- Teste:
- Execução de um programa através de procedimentos manuais ou
automáticos.
- Revisão/Inspeção:
- Revisão de produtos de trabalho por especialistas: documentos,
código-fonte de programas.
- Prova/Verificação:
- Procedimento sistemático e formal para garantir que uma implementação
está correta.
- Métrica:
- Aferição de características mensuráveis dos produtos de trabalho ou da
execução de programas.
|
|
6
|
- à Levantamento de
requisitos
- à Análise
- àDesign de alto nível
- à Design detalhado
- à Codificação
- + teste unitário
- à Integração
- + teste de integração
- à Implantação
- + teste de sistema
- àManutenção
- + teste de regressão
|
|
7
|
- s. f. (do italiano cascata)
- 1. Queda de água em cachoeira, natural ou artificial;
- 2. Brasil, gíria: Conversa fiada; mentira; bazófia
- Fonte:
- Dicionário Universal da Língua Portuguesa
- http://www.priberam.pt/DLPO/
|
|
8
|
- Inspeções são sempre mais eficientes que testes na contenção de
defeitos.
- Usar uma matriz para mapear casos de teste X requisitos.
- Só se pode rodar os testes depois de implementar.
- Fazer certo da primeira vez, para evitar retrabalho.
- Procedimentos formais garantem uma implementação correta.
|
|
9
|
- Definir todos os casos de teste antes de começar a programar.
- Se funciona mais ou menos, é melhor não mexer.
- Torcer para o teste dar certo na primeira rodada.
- Automatizar os testes é muito caro: não compensa.
- É impossível que quem vai rodar os testes não entenda este roteiro: está
super claro.
- Vai pegar mal documentar que esse teste falhou: vai ferrar as nossas
métricas.
|
|
10
|
- O teste passou: está 90% certo.
- Testes (ou inspeções, ou provas, ou métricas) garantem qualidade.
- Quem testa não pode ser quem programou.
- Revisar o código muito cuidadosamente antes de compilar: não depender do
compilador para detectar erros triviais.
- Rodar exaustivamente testes de mesa antes de digitar o código.
|
|
11
|
- Para verificar a validade de uma implementação com respeito aos
requisitos.
- Para especificar formalmente o critério de aceitação de uma
implementação pelo cliente.
- Para detalhar o design e a forma de uso da funcionalidade.
- Para garantir que não quebramos nada quando fazemos uma alteração.
|
|
12
|
- Não é técnica de teste: é disciplina de desenvolvimento.
- Todo teste é automatizado.
- Código do teste é escrito antes do código que deve ser testado.
- É bom que o teste falhe na primeira vez.
- Nenhum código funcional é escrito sem testes pré-existentes.
|
|
13
|
- A maioria dos testes roda muito rápido (em segundos).
- Toda implementação tem um jeito razoável de ser testada.
- Ciclo de desenvolvimento na ordem de minutos.
- Toda correção começa com um teste que falha para o defeito a ser
corrigido.
- Escreve-se mais código de teste que código funcional.
|
|
14
|
- Testes do programador
- Testes unitários (caixa branca)
- Codificados pelo desenvolvedor.
- Detalham o design da implementação.
- Rodam muito rápido.
- Todo código integrado roda 100% desses testes.
|
|
15
|
- Testes do cliente
- Testes de sistema (caixa preta)
- Escritos pelo cliente.
- Detalham os critérios de aceitação de uma implementação.
- Podem demorar mais.
- Mais difíceis
- Quando estão rodando 100%, o produto pode ser entregue.
|
|
16
|
- Integração Contínua
- Toda vez que é integrado código, rodam-se os testes
- Todo teste é teste de regressão
|
|
17
|
|
|
18
|
- Entrada: estórias de usuário (requisitos), arquitetura
- 1. Escreva um teste para uma porção ridiculamente pequena da
funcionalidade.
- 2. Compile e rode o teste.
- 3. Escreva o mínimo código funcional para passar o teste (com possível
enganação). Compile.
- 4. Compile e rode o teste
- 5. Melhore o teste para desvendar a enganação, se houver Vá para (2)
- 6. Melhore (refatore) o código funcional. Vá para (2)
|
|
19
|
- Simplificando
- Depurar - o que se faz quando se sabe que o programa não funciona;
- Teste - tentativas sistemáticas de encontrar erros em programa que você
“acha” que está funcionando.
- “Testes podem mostrar a presença de erros, não a sua ausência
(Dijkstra)”
|
|
20
|
- Se possível escreva os testes antes mesmo de escrever o código
- quanto antes for encontrado o erro melhor !!
|
|
21
|
- Teste o código em seus limites;
- Teste de pré e pós condições;
- Uso de premissas (assert);
- Programe defensivamente;
- Use os códigos de erro.
|
|
22
|
- Para cada pequeno trecho de código (um laço, ou if por exemplo)
verifique o seu bom funcionamento;
- Tente ume entrada vazia, um único item, um vetor cheio, etc.
|
|
23
|
|
|
24
|
|
|
25
|
|
|
26
|
- Verificar certas propriedades antes e depois de trechos de código
|
|
27
|
- Solução possível
- Não existe uma única resposta certa
- A única resposta claramente errada é ignorar o erro !!
- Ex: USS Yorktown.
|
|
28
|
- Em C e C++ use <assert.h>
- ex:
- assert (n>0);
- se a condição for violadada:
- Assertion failed: n>0, file avgtest.c, line 7.
- Ajuda a identificar “culpados” pelos erros
|
|
29
|
- Tratar situações que não “podem” acontecer
|
|
30
|
- Checar os códigos de erro de funções e métodos;
- você sabia que o scanf retorna o número de parâmetros lidos, ou EOF ?
- Sempre verificar se ocorreram erros ao abrir, ler, escrever e
principalmente fechar arquivos.
- Em java sempre tratar as possíveis exceções
|
|
31
|
|
|
32
|
|
|
33
|
|
|
34
|
|
|
35
|
|
|
36
|
|
|
37
|
|
|
38
|
- Teste incrementalmente
- durante a construção do sistema
- após testar dois pacotes independentemente teste se eles funcionam
juntos
- Teste primeiro partes simples
- tenha certeza que partes básicas funcionam antes de prosseguir
- testes simples encontram erros simples
- teste as funções/métodos individualmente
- Ex: teste de função que faz a busca binária em inteiros
|
|
39
|
- Conheça as saídas esperadas
- conheça a resposta certa
- para programas mais complexos valide a saída com exemplos conhecidos
- compiladores - arquivos de teste;
- numéricos - exemplos conhecidos, características;
- gráficos - exemplos, não confie apenas nos seus olhos.
|
|
40
|
- Verifique as propriedades invariantes
- alguns programas mantém propriedades da entrada
- número de linha
- tamanho da entrada
- freqüência de caracteres
- Ex: a qualquer instante o número de elementos em uma estrutura de
dados deve ser igual ao número de inserções menos o número de
remoções.
|
|
41
|
- #include <stdio.h>
- #include <ctype.h>
- #include <limits.h>
- unsigned long count[UCHAR_MAX+1];
- int main(void) {
- int c;
- while ((c = getchar()) !=
EOF){
- count[c]++;
- }
- for(c=0; c <= UCHAR_MAX;
c++){
- printf(``%.2x %c %lu\n’’, c,
isprint(c) ? c: `-’,
count[c]);
- return 0;
- }
|
|
42
|
- Compare implementações independentes
- os resultados devem ser os mesmos
- se forem diferentes pelo menos uma das implementações está incorreta
- Cobertura dos testes
- cada comando do programa deve ser executado por algum teste
- existem profilers que indicam a cobertura de testes
|
|
43
|
- Testes manuais
- Testes automatizados
- devem ser facilmente executáveis
- junte em um script todos os
testes
|
|
44
|
- Teste de regressão automáticos
- Comparar a nova versão com a antiga
- verificar se os erros da versão antiga foram corrigidos
- verificar que novos erros não foram criados
- Testes devem rodar de maneira silenciosa
|
|
45
|
|
|
46
|
- Crie testes autocontidos
- testes que contém suas próprias entradas e respectivas saídas esperadas
- programas tipo awk podem ajudar
- O quê fazer quando um erro é encontrado
- se não foi encontrado por um teste
- faça um teste que o provoque
- Como fazer um testador automático para o programa de freqüência ?
|
|
47
|
- As vezes para se testar um componente isoladamente é necessários criar
um ambiente com características de onde este componente será executado
- ex: testar funções mem* do C (como memset)
|
|
48
|
- /* memset: set the first n bytes of s to the byte c */
- void *memset(void *s, int c, size_t n) {
- size_t i;
- char *p;
- p = (char *) s;
- for (i=0; i<n; i++)
- p[i] = c;
- return s;
- }
- // memset(s0 + offset, c, n);
- // memset2(s1 + offset, c, n);
- // compare s0 e s1 byte a byte
|
|
49
|
- Testar com grandes quantidades de dados
- gerados automaticamente
- erros comuns:
- overflow nos buffers de entrada, vetores e contadores
- Exemplo: ataques de segurança
- gets do C - não limita o tamanho da entrada
- o scanf(``%s’’, str) também não...
- Erro conhecido por “buffer overflow error” NYT98
|
|
50
|
|
|
51
|
- Cheque os limites dos vetores
- caso a linguagem não faça isto por você
- faça com que o tamanho dos vetores seja pequeno; ao invés de criar
testes muito grandes
- Faça funções de hashing constantes
- Crie versões de malloc que ocasionalmente falham
- Desligue todos os testes antes de lançar a versão final
|
|
52
|
- Inicialize os vetores e variáveis com um valor não nulo
- ex: 0xDEADBEEF pode ser facilmente encontrado
- Não continue a implementação de novas características se já foram
encontrados erros
- Teste em várias máquinas, compiladores e SOs
|
|
53
|
- “white box”
- testes feitos por quem conhece (escreveu) o código
- “black box”
- testes sem conhecer o código
- “usuários”
- encontram novos erros pois usam o programa de formas que não foram
previstas
|
|
54
|
- Por que não escrever testes
- Quanto maior a pressão
- Com menos testes
- menos produtividade e menor estabilidade
- Logo, a pressão aumenta....
|
|
55
|
|
|
56
|
- Testes unitários não podem depender de estado
- Então, como testar:
- Bancos de Dados
- Servidor Web
- Interface Usuário
- ..., etc.
|
|
57
|
- Coloca-se uma camada que funciona como se o serviço sempre fizesse a
coisa certa, para testar o cliente (mock objects = objetos fajutos)
- O serviço tem testes específicos que verificam seu funcionamento
interno.
|
|
58
|
- Desempenho (JUnitPerf)
- Métricas de qualidade
- Padrões de projeto (PatternTest)
- Cobertura de testes (Jester)
- ... Todas escritas seguindo o padrão Xunit.
- Vantagens
- Integração com ambientes de desenvolvimento (IDEs)
- Feedback rápido
- Robustez
|
|
59
|
- Grupo testdrivendevelopment do Yahoo
- http://junit.org
- Test-driven development (Kent Beck, 2003)
- http://www.xispe.com.br
|
Anotações
