Gerência e Qualidade de Software
1
UNIVERSIDADE ESTADUAL DE MATO GROSSO DO SUL
Curso de Sistemas de Informação
Dourados– MS - 05/09/17
Especial Testes de Software
Introdução
3
1.1 – Definições – próximos passos
Dourados – MS - 05/09/17
INCONSCIENTE
INCOMPETENTE
CONSCIENTE
INCOMPETENTE
CONSCIENTE
COMPETENTE
INCONSCIENTE
COMPETENTE
Pior Situação
O Começo
Aprendizado
Cultura
Pior Situação
O Começo
Futuro
HOJE
4
1.1 – Definições – perspectivas diferentes
Visão do Analista
de Sistemas
Testes para
provar que algo
está correto
Testes para provar que
algo não está correto
Visão do Analista de Testes Cenários Positivos Comuns Cenários Positivos Estendidos Cenários Negativos Estendidos
5
1.1 – Definições – quando guarantir a qualidade?
Dourados – MS - 05/09/17
Modelo
Negócios Requisitos ModelageAnálise e m
Implemen
tação Testes deSoftware Disponibilização
Tempo
6
1.1 – Definições – custos da qualidade
Custo do Projeto Custo do Desenvolvimento Custo da Qualidade Custo da Não-Conformidade Custo da Conformidade Custo da Prevenção de Defeitos -Metodologias; -Treinamento; -Ferramentas; -Políticas; -Procedimentos; -Planejamento; -Análises; -Métricas; Custo da Detecção de Defeitos -Revisões o Problema; o Requisitos; o Modelagem; o Planos de Testes; o Scripts de Testes; -Inspeção de Código; -Testes (1a. execução); -Re-Revisões; -Re-Testes; -Correção oCódigo; oDocumentação; -Re-Estruturação; -Re-Distribuição versão; -Atrasos Cronogramas; -Falhas da Produção;
...
Existe uma co-relação entre os custos da não-conformidade com os investimentos em prevenção de
defeitos. Quanto maior estes investimentos, menor a incidência das
Testes de Verificação
7
8
2.1 – Definições – métodos estruturados de verificação
Qualidade
do
Processo de
Software
Qualidade
do
Processo de
Software
Revisões Revisões Auditorias AuditoriasFoco nas Documentações
9
2.1 – Definições – impacto das revisões
Dourados – MS - 05/09/17
Revisões de Requisitos detectam 15% dos defeitos
Revisões na Análise e Design detectam 30% dos defeitos
10
2.2 – Tipos de Testes- tipos de revisões
Criação
Validação
Divulgação
Autor Irtoprçlh khg ] [gfg~fçlk çj Documento Revisor Autor Irtoprçlh khg ] [gfg~fçlk çj Documento Moderador Grupo de Revisão Grupo de Acompanhamento Irtoprçlh khg ] [gfg~fçlk çj Documento Autor Reunião Acompanhame Reunião Acompanhame Revisão Formal Revisão Formal Revisão Isolada Revisão Isolada
11
2.2 – Tipos de Testes- executando revisões
Dourados – MS - 05/09/17
Um tópico é definido e será escopo das discussões
Uma questão é levantada por um revisor
A questão é discutida e avaliada
Os revisores confirmam a existência do defeito
O defeito é registrado e detalhado para que seja corrigido pelos autores
Outras questões são levantadas até que todas tenham sido analisadas
Um novo tópico é identificado até que todos tenham sido discutidos
12
2.2 – Tipos de Testes- revisões eficientes
Profundidade das Análises e Discussões
Uniformidade das Atividades
Continuidade e Frequência
Revisores Experientes
Presença de um Moderador nas Reuniões
Revisões Curtas e Bem Focadas
Identificar Problemas, e Não Resolvê-los
Concluir as Revisões
13
2.2 – Tipos de Testes-
Checklist para Testes de Verificação
Dourados – MS - 05/09/17 Verificação de Negócios Verificação de Requisitos Verificação Análise e Modelagem Verificação da Implementação Check-List Verificação de Negócios Check-List Verificação Análise e Modelagem Check-List Verificação de Requisitos Check-List Verificação da Implementação
14
2.2 – Tipos de Testes-
Checklist para Testes de Verificação
Modelo de Negócios Implementação Análise e Modelagem
Revisar Contexto do Mercado e Necessidades Cliente; Revisar Riscos do Projeto;
Auditar Alternativas de Execução do Projeto; Revisar Estudo de Viabilidade do Projeto;
Revisar Arquitetura da Aplicação;
Revisar o Modelo Estático do Projeto de Software; Revisar o Modelo Dinâmico do Projeto de Software; Revisar Nível de Componentização;
Revisar Nível de Reutilização; Modelo de Negócios; Análise de Riscos; Arvore de Decisão; Estudo de Viabilidade; Arquitetura da Aplicação; Modelos Estáticos; Modelos Dinâmicos; Modelos Distribuição; Código-Fonte; Componentes; Manual do Usuário; Revisar o Código-Fonte;
Avaliar Complexidade do Código-Fonte; Auditar Rastreabilidade entre Componentes;. Especificação Requisitos;
Rastreabilidade;
Revisar Especificação de Requisitos Funcionais; Revisar Especificação de Requisitos Não-Funcionais; Revisar Priorização de Requisitos;
Auditar Rastreabilidade de Requisitos;
Especificação de Requisitos
Fase da
15
2.2 – Tipos de Testes-
Checklist para Testes de Verificação
16
2.2 – Tipos de Testes-
Checklist para Testes de Verificação
Check-List do Diagramas UML
Diagramas de Classes
- Todas as classes possuem nome e descrição adequados. Sim Não
- Todos os atributos da classe possuem nome e descrição adequados. Sim Não
- Todos os serviços da classe possuem nome e descrição adequados. Sim Não
Diagrama de Estado
- Todas as transições de estado possuem um serviço ou evento
associado. Sim Não
- Todos os estados possuem nome e descrição adequados. Sim Não
- Todas as transições de estado refletem o real ciclo de vida da classe. Sim Não
Diagramas de Componentes
- As “Packages” agrupam componentes com mesmas características. Sim Não
- Cada componente agrupa classes de única camada: user, business, data Sim Não
Testes de Validação
17
18
19
3.1 – Tipos de Testes-
Checklist para Testes de Validação
20
Teste de Software Caixa Branca
e Caixa Preta
21
22
4.1 – Definição –
Teste de Caixa Branca e Teste de Caixa Preta
Caixa
23
4.1 – Definição – a
bordagem
Caixa Branca e Caixa Preta
Dourados – MS - 05/09/17
Caixa Branca
Caixa Preta
24
4.2 – Definição –
Teste de Caixa Branca
Término do
Processamento
Início do
Processamento
Caminho A
Caminho B
25
4.2 – Definição –
Teste de Caixa Preta
Dourados – MS - 05/09/17
Resultados
Gerados
Estímulos
Categoria de Testes
27
4.3 – Categorias de Teste – cenários de teste
Dourados – MS - 05/09/17
- simular saques acima do saldo disponível; - simular saques com cartão vencido;
- avaliar se a duração do saque dura até 30 seg. num universo de 5 milhões de correntistas e 100 milhões de movimentação bancária;
- simular saque com defeito no “cash-dispenser”;
- simular saque com impressora do fornecedor A, B e C; - avaliar se a senha do cartão esta sendo requisitada antes e depois da transação;
- simular 2 saques simultâneos na mesma conta-corrente; - simular saque na conta poupança;
- avaliar se a senha adicional e randômica esta sendo requisitada no início da operação.
- simular saques no Windows 95, 98, NT e 2000; - avaliar se todas as telas possuem ajuda;
Cenários de Testes
Transfer ência Depósito
28
4.4 – Categorias de Teste – categorias
- simular saques acima do saldo disponível;
- simular saque na conta poupança;
- simular saque acima do valor do limite da conta; - simular saque com valores não múltiplos das notas;
- simular saque com valores não múltiplos das notas;
Funcional
- avaliar se a duração do saque dura até 30 seg. num universo de 5 milhões de correntistas e 100 milhões de movimentação bancária;
- garantir que manipulação com dispositivos físicos no saque não ultrapassem 10 seg. da operação;
Performance
- avaliar se todas as telas possuem ajuda;
- avaliar se mensagens são claras e objetivas;
- avaliar se o padrão visual é mantido em todos os momentos; - avaliar se todas as operações possuem caminhos de fuga; Usabilidade
- simular saques com cartão vencido;
- avaliar se a senha do cartão esta sendo requisitada antes e depois da transação;
- avaliar se a senha adicional e randômica esta sendo
requisitada no início da operação;
- simular saque noturno acima do valor permitido;
Segurança
- simular 2 saques simultâneos na mesma conta-corrente; - simular 10.000 saques simultâneos; Carga e Concorrência - disparar processo de instalação emergencial; Contingência - simular saque com defeito no
“cash-dispenser;
- simular saque com defeito na impressora;
- simular saque com falha de conexão com a central; - simular saque com queda de energia;
Recuperação
- simular saque com
impressora do fornecedor A, B e C;
- simular saques no Windows 95, 98, NT e 2000;
- simular saque com impressora do fornecedor X, Y e Z;
29
4.4 – Categorias de Teste – categorias
Dourados – MS - 05/09/17
Características da Aplicação
Importância
01. Funcional
Essencial02. Desempenho Médio Impacto
03. Confiabilidade/Disponibilidade Alto Impacto
04. Segurança Essencial
05. Carga e Concorrência Alto Impacto
06. Usabilidade Médio Impacto
07. Compatibilidade Essencial
08. Portabilidade Baixo Impacto
09. Contingência Alto Impacto
10. Instalação Médio Impacto
11. Distribuição Alto Impacto
Casos de Teste
31
5.1 – Casos de Teste – Caixa Branca
Dourados – MS - 05/09/17 Início do Processamento A C F D E Término do Processamento B I J L G H Abordagem Caixa-Branca A B F E A B C D E A B I L J A G H I J L Caso de Teste 1 Caso de Teste 2 Caso de Teste 3 Caso de Teste 4
32
5.2 – Casos de Teste – Caixa Preta
Requisito A
Caso de Teste A.1 Caso de Teste A.2
Caso de Teste A.3 Caso de Teste A.4
Requisito B Caso de Teste B.1 Caso de Teste B.2 Caso de Teste B.3 Caso de Teste B.4 Abordagem Caixa-Preta
Obtendo Casos de Teste
33
34
6.1 –
Obtendo Casos de Teste -Decomposição de Requisitos
Sistema de Vendas
Realizar Pagamentos
Cenários Alternativos
Cliente realiza pagamento com cheque.
Cliente realiza pagamento com cartão de crédito. Cliente realiza pagamento parcelado.
Cliente realiza pagamento da última parcela. Cliente realiza pagamento adiantado.
Cliente realiza pagamento em atraso.
Cenário Primário
Cliente realiza pagamento em dinheiro.
Cenários de Exceção
Cliente realiza pagamento com cartão inválido. Cliente realiza pagamento com cheque bloqueado.
35
6.2 –
Obtendo Casos de Teste -Análise de Documentos
Dourados – MS - 05/09/17
Diagrama de
Casos de Uso Cenários Positivos E A F E A Cenários Negativos B A C A D A Casos de Testes Identificados B C D E A F Diagrama de Atividades
#include <stdio.h>
/* Nosso Hello World! (c) */
int main (int argc, char** argv)
{
printf(“Hello World!\n”);
return (0);
}
Exercícios- Determinar Caminhos de teste
//quadrado.c//calcula o quadrado de um número #include<stdio.h>
int square( int num1 ) {
return num1 * num1; } int main(){ int number; int result; printf("\nDigite um numero: "); scanf("%d", &number); result = square(number);
Exercícios- Determinar Caminhos de teste
// Aumenta em 1 o número de tentativas tentativas++;
// Verifica se o jogador ganhou ou diminui os limites ao redor do número if(x > n) { limite_superior = x; } else if(x < n) { limite_inferior = x; } else { acertou = 1; } }while(!acertou);
// Imprime o resultado após o jogador ganhar o jogo system("cls");
printf("Parabens, o numero e: %dn", n); printf("Total de tentativas: %dn", tentativas);
// Pausa o programa até alguma tecla ser pressionada system("pause");
return 0; }
//=============================================================== // Descrição: Jogo "Adivinhe o número"
//=============================================================== // Libs #include <stdio.h> #include <stdlib.h> #include <time.h> // Função main
int main(int argc, char** argv) {
int n, x, limite_inferior, limite_superior, acertou, tentativas; // Inicia o gerador de números aleatórios
srand(time(NULL)); // Inicaliza as variáveis
acertou = 0; // Verifica se o jogador acertou o número tentativas = 0; // Total de tentativas
limite_inferior = 0; // Limite inferior limite_superior = 101; // Limite superior
n = (rand() % 100) + 1; // Número gerado aleatoriamente // Loop principal
do {
// Limpa a tela system("cls");
// Imprime o total de tentativas e pede um número ao jogador printf("Total de tentativas: %dn", tentativas);
printf("Digite um numero(Esta entre %d e %d): ", limite_inferior, limite_superior); scanf("%d", &x);
Exercícios- Determinar Caminhos de teste
Exercícios- Determinar Caminhos de teste
Exercícios- Determinar Caminhos de teste
Estágios dos Testes
47
7.1 – Estágios de Teste – Alto e Baixo Nível
Dourados – MS - 05/09/17 Teste de Unidade Teste de Aceitação Teste de Sistema Estratégia Caixa-Branca; Testam partes do software;
Requer conhecimento da estrutura interna;
Executado pelo desenvolvedor ou profissional de teste.
Estratégia de Caixa-Preta;
Os testes são aplicados no software como um todo;
Não requer conhecimento da estrutura interna do software; Requer ambiente muito semelhante ao da produção; Deve ser executado por um grupo de teste independente. Estrutura Interna; Funcionalidade; Usabilidade Segurança; Funcionais; Não Funcionais; o Performance; o Instalação; o Recuperação; o Carga; Funcional; Usabilidade; Segurança; Estratégia de Caixa-Preta;
Os testes são aplicados no software como um todo;
Não requer conhecimento da estrutura interna do software; Requer ambiente muito semelhante ao da produção; Deve ser executado pelos usuários finais.
Interfaces;
Dependências entre Componentes;
Estratégia de Caixa-Branca;
Testam integrações entre partes do software;
Requer conhecimento da arquitetura interna do software; Executado pelo desenvolvedor ou profissional de teste. Teste de
Integração Fase da
Validação Testes AplicadaCategorias de Características daFase de Validação
Teste de alto nível Teste de baixo nível
48
7.2 – Estágios de Teste – Teste de Aceite
Aceite
Formal
Implantação Total Todos os clientes recebem o software devidamente testado. Implantação BETA Clientes selecionados recebem o software para operar em seu ambiente. Clientes planejam erealizam os testes do software.
Aceite Formal
ALPHA
Teste
Teste
BETA
Clientes
Todos
Clientes são convidados a operar o software no fornecedor.
Implantação ALPHA
49
7.3 – Estágios de Teste – Teste de Ambiente
Dourados – MS - 05/09/17 Ambiente de Desenvolviment o Ambiente Teste e Homologação Ambiente de Produção Em Teste Em
Desenvolvimento HomologaçãoEm ProduçãoEm
Ferramentas automatizadas
para Teste de Software Caixa
Preta
51
4.1 – Seleniun
52
4.2 – Firebug
Página
53
Dourados – MS - 05/09/17