Ctai Teste De Software Aula 2

Teste de Software
Victor Hugo Germano
Aula - 02

CTAI SENAISC

Victor Hugo Germano
http://malditacomedia.blogspot.com

Unitários

Transição de Estado

Unitários
Integração


Unitários
Integração


Análise de Valor Limite

Unitários
Integração

Testes de Caminho

Unitários
Integração
Aceitação
Testes de Caminho

TDD

Escreva um teste que falhe

TDD


Faça o teste passar

TDD


Faça o teste passar

Refatore

Testes de aceitação

Por quê?


Por quê?
Direcionar o desenvolvimento
do produto


Pra quê?
Veriﬁcar a completude de um
requisito


Como?


Como?
• Idealmente escritos antes do desenvolvimento
• Idealmente Automatizados
• Garantem que o código faz exatamente o que
se propõe a fazer

Tempo

1 2 3 4

Explorar Requisitos
Deﬁnir Testes de Aceitação
para Use Cases

Tempo

garantes conformidade
com os requisitos

1 2 3 4

Explorar Requisitos
Deﬁnir Testes de Aceitação
para Use Cases

Selenium

http://seleniumhq.org/

Selenium IDE
172.16.4.19

Test Suite
<html>
<head>
<title>My Application Test Suite</title>
</head>
<body>
<table>
<tr><td><b>Suite Of Tests</b></td></tr>
<tr><td><a href=quot;./TestLogin.htmlquot;>Test Login</a></td></tr>
<tr><td><a href=quot;./TestFormEntry.htmlquot;>Test Form Entry</a></td></tr>
<tr><td><a href=quot;./TestFormSave.htmlquot;>Test Form Save</a></td></tr>
</table>
</body>
</html>

Exercício V

Integrar Testes numa
suite de testes de aceitação

Exercício V
Construir testes de aceitação
Na página principal, devem haver links para outros serviços
do google: orkut, email, Imagens e Mapas

Na pagina de Busca avançada, selecionar o idioma Ingles e
buscar por “linux” deve retornar a pagina da wikipedia em
inglês como primeiro item da busca

Uma consulta que não apresenta resultados deve
apresentar uma mensagem de indicação

Quando Parar de testar?

Custo


Custo
Prazo


Custo
Prazo
Cliente

Test Cases
Comunicação
Encontrar problemas antes que o cliente o faça

Test Cases
Comunicação
Evitar que problemas ocorram

Test Cases
Comunicação
Evitar que problemas ocorram
Auxiliar na tomada de decisão

Test Cases

Aderência aos requisitos de negócio,
não de sistema

Test Cases

Redução de Riscos

Medir a Qualidade

Encontre as prioridades do projeto!

Um único objetivo por vez!

Está tudo claro? Pergunte!

Está tudo claro? Pergunte!
Pare e pense!

Test Cases
Qualidades
Fácil de ler
- Não há lugar para enrolação!

Test Cases
Qualidades
Fácil de ler
Rápido de encontrar o resultado esperado
- Interpretação em poucos segundos

Test Cases
Qualidades
Fácil de ler
Autoexplicativos
- Não necessitam da especiﬁcação completa do sistma

Test Cases
Qualidades
Fácil de ler
Autoexplicativos
- Não necessitam da especiﬁcação completa do sistma
Curtos
- Elimine todos os desperdícios!

Easy to Test Language
- Seja imperativo
quot;clique no botãoquot;, quot;vá ao item 1quot;
- Seja direto e simples, porém não simplório
- Use nomes exatos e consistentes para campos,
não seja genérico
- Entre 10 e 15 passos
- Siga convenções de nomes
- Se não existem convenções, CRIE-AS!!!

Atributos Comuns
• Identificador
• Descricao
• Prioridade
• Pre-condição
• Dependências
• Entradas
• Instruções de utilização
• Resultados esperados
• Resultado Atual
• Pós-condições
• Resultado (passou/falhou)
• Número da versao

Linhas Gerais
Escrever testes juntamente com os requisitos

Linhas Gerais
Descrevem o atual requisito

Linhas Gerais
Siga um padrão, facilite a comunicação

Linhas Gerais
Priorize seus testes por valor de negócio

Linhas Gerais
Agrupe testes por domínio

Linhas Gerais
Agrupe testes por domínio

Foque no valor! Foque no resultado!

Pratique!!
A prática leva à perfeição

Pratique!!

Priorize!
Remova
desperdícios!

Pratique!!

Priorize!
Remova
desperdícios!

Se possível,
automatize!
Seja preguiçoso!

Exercício VI
Sistema de Vendas

Construir testes de aceitação
para módulo Fazer Pedido

http://www.consiste.dimap.ufrn.br/~andre/casouso/

Exercício VI
Fazer Pedido - versão 4
Atores
Cliente
Pré-condição:
O usuário deve ter feito quot;log-inquot; e obtido autorização
do sistema
Pós-condição:
O pedido deve ter sido gravado no sistema e marcado
como conﬁrmado.

Applying Use Cases: A Pratical Guidequot;, Geri Schneider & Jason Winters, Addison-Wesley, 1998.

Fazer Pedido - versão 4
Fluxo de eventos primário:

1.
O caso de uso começa quando po cliente seleciona quot;fazer pedidoquot;.

2.
O cliente fornece seu nome e endereço.

3.
Se o cliente fornece apenas o CEP, o sistema coloca automaticamente o a cidade e o
estado.

4.
Enquanto o cliente quiser pedir itens faça

1.
O cliente fornece código do produto

2.
O sistema fornece as descrição e preço do produto

3.
O sistema atualiza o valor total

5.
O cliente fornece as informações sobre cartão de crédito.

6.
O cliente submete os dados ao sistema.

7.
O sistema verifica as informações fornecidas, marca o pedido como quot;pendentequot; e envia as
informações de pagamento para o sistema de contabilidade e pagamento.

8.
Quando o pagamento é confirmado, o pedido é marcado como quot;confirmadoquot; e o número
de pedido (NP) é dado ao cliente.
Fluxo de eventos secundário:
A qualquer momento antes de submeter, o cliente pode selecionar cancelar. O pedido não é
gravado e o caso de uso termina.
No passo 7, se alguma informação estiver correta, o sistema pede ao cliente para corrigir a
informação.
Applying Use Cases: A Pratical Guidequot;, Geri Schneider & Jason Winters, Addison-Wesley, 1998.

Por que planejar?
Finalidade:
• Localizar e documentar defeitos na qualidade do
software.
• Avisar de forma geral sobre a qualidade
observada no software.
• Validar as suposições feitas nas especificações
de design e requisito através de demonstração
concreta.
• Validar as funções do software conforme
projetadas.
• Verificar se os requisitos foram implementados
de forma adequada.

Teste antes, teste sempre!
Comunique-se!

Comunique-se!
Comunique-se!

Comunique-se!
Comunique-se!
Se puder, automatize!

Comunique-se!
Comunique-se!
Se puder, automatize!
Entenda o domínio do negócio

Introdução

Visão Geral:
- Escopo, métodos, Padroes

Introdução

Visão Geral:
- Escopo, métodos, Padroes

Requisitos:
- Hardware, software, Pessoal

Template
Interação Homem-Computador
• descrição,
• objetivos,
• métodos,
• objetos a serem testados,
• eventos a serem testados,
• veriﬁcação dos testes,
• ferramentas de teste.

Template
Testes Funcionais
• objetivos,
• métodos,
• funções a serem testadas,
• projeto de dados para testes,
• construção dos dados de teste,
• verﬁcação do teste,
• ferramentas de teste

Template
Testes de regressão
•Objetivos
• O que não funciona mais e o que
continua funcionando na nova versão
• Dados para teste
• quais casos serão reutilizados
• Execução dos testes
• Ferramentas de teste

Template
Testes de desempenho
• Objetivos
• Métodos de teste
• Monousuário
• Multiusuário
• Criação dos dados de teste
• Verﬁcação do teste

Template
• Objetivos
•Cenários de negócio a serem
testados
• Projeto dos casos de teste

Template
Testes de Sistema

• Objetivos
• cenários de negócio a serem testados
• Projeto dos casos de teste

Documentar um Bug

•
Seja preciso

•
Seja claro - explique de forma que outros
possam reproduzir o erro

•
Um bug por relatório

•
Nenhum bug é simples o suﬁciente para não
ser registrado

•
Separe claramente fatos de especulações

•
Um printscreen vale mais que mil parágrafos

Documentar um Bug
“Eu estava usando o sistema e então ele deu pau”

Documentar um Bug
“Eu estava usando o sistema e então ele deu pau”

-> Abra o sistema e vá ao item quot;Arquivo > Novoquot;
-> Desenhe uma Reta
-> Vá até a função quot;Salvar Como...quot; e salve o arquivo
-> Tente abrir o arquivo novo
-> Veriﬁque a mensagem de erro

Análise de Risco & Prioridades

Analise de Risco

Use Case Cenário Risco Frequência Criticidade

UserCase 1 Cenário A Alto Alta Baixa

UserCase 2 Cenario B Médio Baixa Alta

Priorização
Modelo Kano

Priorização Pelo Valor Percebido

Modelo Kano

http://en.wikipedia.org/wiki/Kano_model

Modelo Kano

Obrigatórios
Must-have


Modelo Kano

Obrigatórios
Must-have

Quanto mais, melhor!
Linear


Modelo Kano

Obrigatórios
Must-have

Quanto mais, melhor!
Linear
Necessidades não
Exciters
conhecidas


Modelo Kano
2 Perguntas:

http://www.acarlos.com.br/blog/

Modelo Kano
2 Perguntas:
O que você acha de ter uma
Funcional cerveja de graça no quarto de
hotel todos os dias?


Modelo Kano
2 Perguntas:
O que você acha de ter uma
Funcional cerveja de graça no quarto de
hotel todos os dias?

Chegar em um hotel que não
DysFunctional tem cerveja grátis, o que você
acha?


Modelo Kano
DysFunction Question

Live with
Neutral
Expect

Dislike
Like
M - Mandatory
L - Linear
Like Q E E E L
Functional Question

E - Exciter
Expect R I I I M
Q - Questionable
Neutral R I I I M R - Reverse
I - Indifferent
Live with R I I I M
Dislike R R R R Q

Benefício Relativo


Benefício Relativo
Pré-requisito: Estimativas criadas


Benefício Relativo
Beneﬁts Penalties Sum(BV) Estimation BV/Est
Feature 1 1 9 10 2 5
Feature 2
Feature 3
Feature 4
Feature 5

Benefício Relativo
Feature 1 1 9 10 2 5
Feature 2 2 3 5 5 1
Feature 3
Feature 4
Feature 5

Benefício Relativo

Feature 5
Feature 1
Feature 3
Feature 4
Feature 2

Benefício Relativo
Feature 1 1 9 10 2 5
Feature 2 2 3 5 5 1
Feature 3 5 1.6 13 8 8
Feature 4 6 7 13 13 1
Feature 5 5 5 10 2 5

Ctai Teste De Software Aula 2

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Ctai Teste De Software Aula 2

Semelhante a Ctai Teste De Software Aula 2 (20)

Mais de Victor Hugo Germano

Mais de Victor Hugo Germano (20)

Ctai Teste De Software Aula 2