Slides da apresentação sobre teste realizada no primeiro hangout do Dev in PF. Apresentado por: Aline Zanin

1. Fundamentos de
Testes de Software
Maio 2014

2. Quem Sou Eu?
● Aline Zanin;
● Graduada em Análise e Desenvolvimento de
Sistemas - UPF 2011;
● Especialista em Qualidade de Software -
Unisinos 2013;
● Mestranda PUCRS - Ciência da Computação
● Pesquisadora - Centro de Pesquisa em
Engenharia de Sistemas PUCRS -DELL

3. Agenda
● Porque Testar;
● Tipos de Testes;
● Metodologia de Testes;
● 7 Fundamentos de Testes;
● Casos de Teste;
● Cenários de Testes;
● Conclusão.

4. Oque são testes?
Teste é o processo de executar um programa
com o objetivo de verificar sua conformidade
em relação aos requisitos
especificados.

5. Porque Testar Seu Software?
● De acordo com estatísticas um cliente
insatisfeito comenta com outras cinco pessoas
no mínimo que está insatisfeito enquanto um
cliente satisfeito elogia a apenas uma pessoa.
● O desenvolvedor, é o responsável pela criação
do software sendo assim se realizar testes irá
seguir o “caminho feliz”

6. Porque Testar Seu Software?
● Quando cliente se depara com uma falha
em seu sistema ocorre uma quebra de
confiança.
● Uma falha que atinge o cliente pode causar
danos financeiros milhares de vezes maior
que o custo de teste*

7. Regra10 de Myers

8. Defeito
Qualquer condição que causa um desvio de um
resultado baseado no que diz um requisito, um
documento de especificação, um documento do
usuário, um padrão, ou conforme a experiência ou
percepção do técnico, que requeira investigação.

9. Erro
O Erro pode ser um resultado de um defeito ou
uma falha, como um retorno esperado, que por
causa de uma falha teve um valor diferente do que
esperado.

10. Falha
Esta mais ligada ao hardware, como uma rede
inacessível, queda de energia. Uma falha pode
ocorrer por causa de um erro, ou não.

11. Princípios Fundamentais
Princípio 1 – Teste demonstra a
presença de defeitos
O teste pode demonstrar a presença de defeitos,
mas não pode provar que eles não existem. O
Teste reduz a probabilidade que os defeitos
permaneçam em um software, mas mesmo se
nenhum defeito for encontrado, não prova que ele
esteja perfeito.

12. Princípios Fundamentais
Princípio 2 – Teste exaustivo é impossível
Testar tudo (todas as combinações de
entradas e pré-condições) não é viável, exceto
para casos triviais. Em vez do teste exaustivo,
riscos e prioridades são levados em
consideração para dar foco aos esforços de
teste.

13. Princípios Fundamentais
Princípio 4 – Agrupamento de defeitos
Um número pequeno de módulos contém a
maioria dos defeitos descobertos durante o
teste antes de sua entrega ou exibe a maioria
das falhas operacionais.

14. Princípios Fundamentais
Princípio 5 – Paradoxo do Pesticida
Pode ocorrer de um mesmo conjunto de testes
que são repetidos várias vezes não
encontrarem novos defeitos após um
determinado momento.

15. Princípios Fundamentais
Princípio 6 – Teste depende do contexto
Testes são realizados de forma diferente
conforme o contexto. Por exemplo, softwares
de segurança crítica são testados
diferentemente de um software de comércio
eletrônico.

16. Princípios Fundamentais
Princípio 7 – A ilusão da ausência de erros
Encontrar e consertar defeitos não ajuda se o
sistema construído não atende às expectativas
e necessidades dos usuários.

17. Tipos de Testes de Software.
- Caixa Branca
Feito junto ao código durante o processo de
desenvolvimento.
- Caixa Preta
Executado a nível de aplicação, sem contato com código.

18. Tipo de Testes de Software.

19. Teste Funcional Testar as funcionalidades, requerimentos, regras de negócio
presentes na documentação. Validar as funcionalidades
descritas na documentação (pode acontecer de a
documentação estar inválida)
Teste de Interface
Verifica se a navegabilidade e os objetivos da tela funcionam
como especificados e se atendem da melhor forma ao usuário.
Teste de Performance Verifica se o tempo de resposta é o desejado para o momento
de utilização da aplicação.
Teste de Volume
Testar a quantidade de dados envolvidos (pode ser pouca,
normal, grande, ou além de grande).
Teste de Unidade Teste em um nível de componente ou classe. É o teste cujo
objetivo é um “pedaço do código”.
Teste de Integração Garante que um ou mais componentes combinados (ou
unidades) funcionam. Podemos dizer que um teste de
integração é composto por diversos testes de unidade*1

20. Tipo de Testes de Software.
Teste de regressão Toda vez que algo for mudado, deve ser testada toda a
aplicação novamente.
Teste de aceitação do usuário
Testa se a solução será bem vista pelo usuário. Ex: caso
exista um botão pequeno demais para executar uma função,
isso deve ser criticado em fase de testes. (aqui, cabem
quesitos fora da interface, também).
Testes de stress Testar a aplicação sem situações inesperadas. Testar
caminhos, às vezes, antes não previstos no
desenvolvimento/documentação.
Testes de Configuração
Testar se a aplicação funciona corretamente em diferentes
ambientes de hardware ou de software.

21. Tipo de Testes de Software.
Testes de Instalação Testar se a instalação da aplicação foi OK.
Teste de carga
Verifica o funcionamento da aplicação com a
utilização de uma quantidade grande de
usuários simultâneos.
Testes de Segurança Testar a segurança da aplicação das mais
diversas formas. Utilizar os diversos papéis,
perfis, permissões, para navegar no sistema.

22. Técnicas de Testes de Software
● Partição de Equivalência;
● Análise do Valor Limite;
● Tabela de Decisão;
● Teste de transição de estados;
● Técnicas baseadas na experiência;

23. Por onde Começar
Um bom começo seria identificar os cenários
que serão testados nesta aplicação
CENÁRIO DE TESTES ???

24. Cenário de Teste
Cenário de teste descreve o que deve ser
testado amplamente. O cenário de testes é o
passo inicial para a criação do caso de teste.
Ex: 01 - Cadastro de Clientes
Este cenário tem a cobertura do cadastro de
clientes, aplicação deve permitir cadastrar

25. Definir Cenários de Teste
Descrição: O Analista de Teste com base nos requisitos
de teste ou nos casos de uso, e usando o Plano de
Teste como referência, deve definir os Cenários de
Teste e que servirão posteriormente para a elaboração
dos Procedimentos (ou Roteiro) de Teste.
Responsáveis: Analista de Teste
Participantes: Analista de Sistemas, Testador
Artefatos: Plano de Teste, Requisitos, Casos de Uso
(testáveis)
Ferramentas: Precisam ser definidas

26. · Fluxo Principal:
o P 1 – Usuário seleciona o menu “Alterar Senha”
o P 2 – O sistema gera um código aleatório
o P 3 – O sistema carrega a tela “Alteração de Senha”
o P 4 – Usuário entra com sua identificação, a senha atual, a nova senha, a
confirmação da nova senha e o valor do código aleatório (A1)
o P 5 – O usuário confirma a alteração (A2)
o P 6 – O sistema valida a senha. (E1) (E2)
o P 7 – O sistema emite a mensagem de indicação de sucesso
o P 8 – O caso de uso é finalizado
· Fluxo Alternativo 1: O usuário não visualiza código aleatório
o A 1.1 – O usuário seleciona opção “Não consegui visualizar o código”
o A 1.2 – O sistema retorna ao fluxo principal (P2)
· Fluxo Alternativo 2: O usuário cancela a alteração
o A 2.1 – O usuário seleciona a opção cancelar
o A 2.2 – O sistema cancela a operação
o A 2.3 – O caso de uso é finalizado

27. Fluxo de Exceção 1: Confirmação de senha nova não confere com a
mesma
o E.1.1 – O sistema identifica que a nova senha fornecida e a
confirmação da mesma, não conferem.
o E.1.2 – O sistema emite a mensagem “A confirmação da Nova Senha
não confere.”
o E.1.3 – O sistema retorna ao fluxo principal (P4) para entrada da
confirmação da senha nova do usuário.
Fluxo de Exceção 2: Campo Requerido Não Fornecido ou Inválido
o E.2.1 – Usuário não entra com campo requerido
o E.2.2 – O sistema emite a mensagem “Campo requerido ausente ou
inválido.”
o E.2.3 – O caso de uso é finalizado

28. Cenário Fluxo
Cenário 1 P1-P8
Cenário 2 P1-P4 / A1.1
Cenário 3 P1-P5 / A2.1-A2.3
Cenário 4 P1-P4 / E1.1-E1.3
Cenário 5 P1-P4 / E2.1-E2.3

29. Caso de teste é um conjunto de condições usadas para
teste de software. Ele pode ser elaborado para identificar
defeitos na estrutura interna do software, através de
situações que exercitem adequadamente todas as
estruturas utilizadas na codificação; ou ainda, garantir
que os requisitos do software que foi construído sejam
plenamente atendidos.
Casos de Testes
Fonte: Wikipedia =D

30. Casos de Teste
Positivos:
Descrevem Operações que devem ser concluidas na aplicação.
Ex: Efetuar Login com sucesso
Negativos:
Descrevem Operações que não devem ser concluidas na
aplicação.
Ex: Efetuar Login com usuário inválido.

31. Casos de Testes
É importante que os casos de testes possuam as seguintes
informações:
Identificador: um nome único que permita a identificação do
caso de teste.
Histórico de versões: lista as versões do documento,
identificando o que foi alterado e o responsável por cada versão.
Descrição: descreve o objetivo e o escopo do caso de teste.

32. Casos de Testes.
Comportamento esperado: descreve o comportamento
esperado do sistema durante e após a execução do teste. Nesta
seção devem ser incluídas tanto as condições de sucesso,
quanto as de falha.
Comportamento obtido: descreve o comportamento obtido
através da execução do cenário de teste.
Histórico de execuções: descreve a data na qual o cenário de
teste foi executado, qual foi o resultado do teste (passou ou
falhou) e qual a forma de execução (automático ou manual).

33. Conclusão
● Testes de software não garantem a ausência de defeitos,
porém, diminuem a incidência destes aumentando a
qualidade do software.
● Diversas são as formas de organizar um processo de testes,
a organização por cenários e casos de testes permite um
mapeamento melhor da aplicação evitando que partes
importantes não sejam testadas.
● Manter os artefatos de testes atualizados é vitál para ter um
bom resultado com os testes.

34. ?
aline.zanin@acad.pucrs.br

35. Referências - Mais informações
Brasiliam Software Testing Qualification Board
http://www.bstqb.org.br/
Casos de Teste http://www.emersonrios.eti.br/Artigos/Microsoft%
20PowerPoint%20-%20Casos%20de%20Teste%20de%20Software%20%20-
%203%20horas%20Conclu%C3%ADdo.pdf