27/09/2019

Panorama Histórico
• O que é teste?
“Provas destinadas a avaliar conhecimentos,
Testes de Software aptidões ou competências”.

• Quando surgiu?
Antes dos hominídeos.

Luiz Henrique Pereira Niero

• Exemplos:
Engenharia de Software
PPG Ciência da Computação

O Surgimento de teste de software

• 1979 – A arte do teste de software, Glenford
Myers.
• Lista de livros vendidos por 25 anos.
• Versão atual possui a mesma filosofia.
• Divisão de custos 50-50 se manteve.

1
 27/09/2019

Verificação e Validação (V&V)

Parte 1 • Teste é parte do processo de V&V.

• Objetivo: O software está pronto

Resumo
(confiabilidade)?

• Análise de Requisitos -> Entrega do projeto

Verificação e Validação (V&V) Tipos de testes

• Teste de validação;
• Verificação: Estamos construindo o produto • Teste de defeito.
certo? (Atende aos requisitos ?)

• Validação: Estamos construindo o produto da

maneira certa? (Atende as expectativas ?)

Abrangência dos testes

• “Os testes mostram apenas a presença de
Prioridade dos testes erros, e não sua ausência”
De defeitos
Testes de (Dijkstra et al. 1972)
Validação

2
 27/09/2019

Natureza dos testes Estágios dos testes

• Manuais;
• Automatizados:
– Programa específico para teste;
– Nunca poderão ser totalmente automatizados,
devido à dificuldade de simular um ambiente real.
• Testes de desenvolvimento (projetistas e
programadores);
• Testes de release (equipe de testes);
• Testes de usuário (usuários);

Testes de Desenvolvimento SISTEMA

COMPONENTE
• Objetivo: Descobrir bugs; COMPONENTE
• Intercalados com a depuração;
Obj
• Três níveis de granulidade: Obj
Obj
Obj
– Teste unitário (Objetos e métodos);
– Teste de componentes (Interface dos COMPONENTE
componentes);
– Teste de sistema (Iterações entre os
Obj Obj
componentes).

Teste Unitário Teste Unitário – Transição de estados

• Testar operações associadas ao objeto;

– Testar cada transição de estado possível

• Definir e verificar valores dos atributos do objeto;

• Casos de teste:
– Funcionamento normal;
– Funcionamento anormal.

• Automatizar sempre que possível.

3

Teste unitário – Estratégias de escolhas
de casos de teste
• Domínios de equivalência;
Teste de Componente
• Casos de teste aplicados à interface criada pela integração dos
componentes
• Erros mais comuns em sistemas complexos
Diretrizes para o teste de interfaces
• Chamar componentes externos com valores
extremos;
• Passagem de parâmetros de ponteiros nulos;
• Parâmetros que causam falha em um
componente;
• Floodar sistemas com timming;
Inspeções e Avaliações são mais eficazes que
testes em linguagens fortemente tipadas.
27/09/2019
Teste unitário – Estratégias de escolhas
de casos de teste
• Diretrizes de testes
– Entradas que forçam o sistema a gerar as
mensagens de erros;
– Entradas que causam overflow de buffer de
entrada;
– Repetir mesma entrada várias vezes;
– Forçar geração de saídas inválidas;
– Forçar cálculos muito grandes ou muito pequenos.
Teste de Componente – Erros comuns
• Mau uso de interface;
– Parâmetros passados na ordem errada;
• Mau entendimento de interface;
– Passagem de estruturas incorretas;
• Erros de timming.
– Mensagens em times diferentes, assincronismo.
Testes de Sistema
• É nesse momento que são unidos
componentes desenvolvidos separadamente;
• É um teste que pode envolver várias equipes.
• O comportamento da união de componentes
pode não ser desejado.
• Componentes que já funcionavam podem
deixar de funcionar quando integrados.
• Difícil automatizar
4

Diretrizes para o teste de sistema
• Seguir o diagrama de casos de uso;
• É difícil saber o quanto de teste é necessário;
• Impossível testar exaustivamente todas as
possibilidades.
– (basear em subconjuntos de casos).
Parte 2
Desenvolvimento Dirigido a Testes
(DDT)
Processo Fundamental do DDT
27/09/2019
Dicas de conjuntos de testes de
sistema
• Testar todas as funções acessadas por menus;
• Combinações de funções acessadas por
menus;
• Testar funções com entradas corretas e
incorretas (quando fornecidas).
O que é
• Uma abordagem de desenvolvimento.
• Intercala Desenvolvimento e teses.
• Não caminha para o próximo incremento
enquanto o anterior não passar nos testes.
• É parte da metodologia XP.
Automação de Testes
• Ambiente automatizado é fundamental:
– Código é desenvolvido em pequenos incrementos;
– A cada incremento são refeitos todos os testes.
5
 27/09/2019

Por que utilizar o DDT? Mais sobre o DDT

• Melhor entendimento do problema;
• Cobertura do código por testes;
• Testes de regressão para descobrir novos bugs;
• Simplifica a depuração;
• Documentação do sistema.
• Ainda assim, necessita de testes de sistema.
• Abordagem de sucesso para pequenas e
médias empresas.
• Programadores consideram o DDT produtivo
(JEFFRIES e MELNIK, 2007).

Muito caros, impraticáveis (tempo e esforço)

quando o sistema é montado manualmente

Destino do Release
Parte 3 • Clientes;
• Outras equipes de desenvolvimento
(integração);
Testes de Release

Teste de Release x Teste de Sistema Características dos testes de releases

• Duas principais diferenças
– Teste de release é feito por uma equipe que não
fez parte do desenvolvimento;
– Objetivo
• Teste de Sistema: Teste de Defeitos;
• Teste de Release: Teste de validação.
• Objetivo Principal: Mostrar que o produto está
pronto;
• O sistema é tratado como caixa-preta;
• Também chamado “Teste Funcional”. O
testador só está preocupado com a
funcionalidade.

6
 27/09/2019

Tipos de Testes de Release Testes Baseados em Requisitos

• Requisitos devem ser testáveis (boa prática);
• Testes baseados em Requisitos; • Criar conjuntos de testes para cada requisito;
• Testes de Cenário; • Objetivo: Mostrar que o requisito foi
• Testes de Desempenho. implementado adequadamente;

Testes de Cenário Testes de Desempenho

• Imagina cenários e os usa para testar;
• Cenário = estória que descreve uma maneira
de usar o sistema;
• Stakeholders relacionam-se com o cenário.
• Após o sistema ser totalmente integrado;
• Devem assegurar que o sistema suporta a
carga a que se destina;
• Estratégias:
– Aumentar a carga até que o sistema falhe;
– Construir um perfil operacional de testes;
– Testes no limite do sistema (teste de estresse)

Destino
• Usuários e clientes;
Parte 4 • Feito após os testes de Release;
• Importante:
Testes de Usuário – Influência do ambiente de trabalho do usuário;
– Testes até aqui foram “artificiais”.

7
 27/09/2019

Tipos de Testes de Usuário Teste Alfa

• Usuário e Desenvolvedores;
• Teste Alfa; • Usuários identificam problemas e informam a
• Teste Beta; equipe;
• Teste de Aceitação. • Bastante utilizado em metodologia ágil;
• Usado em sistemas customizados.

Teste Beta Testes de Aceitação

• Define se o sistema será ou não aceito;
• Um release é disponibilizado aos usuários;
• Não usado em desenvolvimento ágil;
• Clientes selecionados para testar o sistema
(exemplo eSocial - 2017); • Processo:
• Usados por produtos abrangentes;
• Forma de Marketing.

Exemplo: Testando aplicações web

O ambiente web:
• A web é um mercado crítico de bens e serviços;
Parte 5 • Os possíveis erros não podem ser subestimados;
• Se seu site não é rápido e intuitivo, você perderá o cliente;
Exemplo • Usuários aceitam um sistema desktop mediano, mas não um
site;
• Sites ruins podem comprometer a imagem da companhia:
web sites são a nova “primeira impressão” das empresas.

8

Exemplo: Testando aplicações web
A arquitetura do ambiente 3 camadas (mais
comum):
Exemplos de testes por camada
• Camada de aplicação:
– Verificar as fontes dos browsers;
– Verificar se os links não estão quebrados;
– Verificar resolução e tamanho das imagens;
– Verificar a ortografia de cada página;
– Verificar a posição do cursor quando a página
carrega;
– Verificar o botão selecionado quando a página
carrega;
Exemplo: Testando aplicações web
• Camada de dados:
– Garanta que as operações no banco atendam ao
desempenho esperado;
– Verifique se os dados estão armazenados
corretamente;
– Verifique se é possível recuperar os dados
corretamente à partir dos backups;
– Teste operações de falha ou redundância.
27/09/2019
Exemplo: Testando aplicações web
• Os desafios:
– Diferentes tipos de usuários: habilidades, browsers,
sistemas operacionais;
– Ambiente de negócios: Cálculos de impostos, fretes,
conclusão de transações financeiras;
– Localidades: Usuários podem residir em ouros países;
– Ambiente de testes: É necessário duplicar todo o
ambiente (servidores, equipamentos de rede);
– Segurança: Proteger de hackers, ataques DoS, roubo de
dados.
Exemplo: Testando aplicações web
– Verificar o cálculo adequado dos impostos e
fretes;
– Garantir que os tempos de resposta estão dentro
do esperado;
– Verificar se as transações são concluídas
corretamente;
– Garanta que as transações não completadas serão
desfeitas corretamente;
– Garanta que a data e hora sejam coletados
corretamente.
Exemplo: Testando aplicações web
• Outros pontos a considerar
– Falhas de conexão com a internet;
– Monitorar os logs;
9
 27/09/2019

Artigo
• Titulo: Pontos de vista de profissionais sobre boas
Parte 6 práticas de teste de software.
• Autores: KOCHHAR, Pavneet Singh; XIA, Xin; LO,
David.
Artigo • Local: Proceedings of the 41st International
Conference on Software Engineering: Software
Engineering in Practice
• Repositório: IEEE Press, 2019. p. 61-70.

Classes Hipóteses Aceitação

Pontos de vistas dos profissionais sobre boas (5 – 1)

práticas de testes de softwares Conteúdo • Bons testes devem explorar o fluxo normal e anormal do 4,47
sistema;
• Os testes devem executar com os valores extremos de um 4,24
• Metodologia: domínio;
– Entrevistas com profissionais; • Testes devem ser independentes; 3,95
• Testes devem servir como boa referência para documentação 3,93
– Geração de 29 hipóteses;
• Cada teste deve ser direcionado a um aspecto de um
– Validação das hipóteses com outros profissionais. requisito. 3,93
• Resultados Tamanho e • Testes muitos complexos podem trazer erros em seu próprio 4,04
– As respostas foram agrupadas para formar hipóteses, que foram Complexidade código;
divididas em classes; • Um bom conjunto de testes contém muitos testes pequenos 3,97
e poucos testes grandes;
– As hipóteses foram validadas por mais profissionais. • Casos de testes devem ter poucas linhas de código; 3,85
• Casos de testes grandes são difíceis de entender e dar 3,73
manutenção;
• Casos de testes grandes podem ser necessários para 3,59
Os grupos de hipóteses e as 2 hipóteses mais aceitas foram: encontrar erros difíceis.

Classes Hipóteses Aceitação

(5 – 1) Classes Hipóteses Aceitação
Cobertura • Maior cobertura não significa que o teste pode detectar 4,02 (5 – 1)
mais erros; Detecção de • Testes assertivos podem detectar erros sutis que passariam 4,51
• Direcionar testes para cobrir diferentes requisitos é mais 4,00 Erros despercebidos;
importante que direcionar para cobrir mais código; • Quando um erro é corrigido, é bom adicionar um teste que o 4,40
• Cobrir todo o código é necessário mas não suficiente; 3,97 cubra;
• A cobertura do código deve ser usada para entender o 3,97 • Um bom caso de teste deve tentar interromper o sistema; 4,11
que está faltando no teste e então criar testes baseando- • É interessante inserir comentários no código do teste sobre a 3,98
se nisso; depuração das falhas encontradas;
• Um caso de teste escrito para dar cobertura máxima no 3,50 • Teste até as coisas mais simples, que não podem dar errado. 3,89
código geralmente não é compreensível e quebra
facilmente. Outros • Testes são independentes. A ordem de execução não deve 4,28
alterar as saídas;
Manutenibilidade • Um bom caso de teste deve ser bem modularizado; 4,62 • Um bom caso de teste deve ser projetado para que seu 4,07
• Um bom caso de teste ser legível e de fácil 4,58 resultado seja determinístico.
entendimento; • Testes podem ser separados em categorias, como “testes 3,93
• Os casos de teste devem ter o código mais simples que o 4,20 rápidos”, “testes lentos”, para ser mais fácil executar
código que está sendo testado; conjuntos de testes específicos em determinado tempo
• O código de teste deve ser projetado se pensando na 4,16
manutenção, devido à evolução do código a ser testado;
• Links de rastreabilidade devem ser mantidos entre o 3,97
código fonte, código dos testes e requisitos

10
 27/09/2019

Referências
• SOMMERVILLE, Ian. Software engineering 9th Edition. ISBN-
10137035152, 2011.

Obrigado! • MYERS, Glenford J.; SANDLER, Corey; BADGETT, Tom. The art
of software testing. John Wiley & Sons, 2011.

• KOCHHAR, Pavneet Singh; XIA, Xin; LO, David. Practitioners'

views on good software testing practices. In: Proceedings of
the 41st International Conference on Software Engineering:
Software Engineering in Practice. IEEE Press, 2019. p. 61-70.

11