GQS - especial testes

(1)

Gerência e Qualidade de Software

1 UNIVERSIDADE ESTADUAL DE MATO GROSSO DO SUL

Curso de Sistemas de Informação

Dourados– MS - 29/08/17

(2)

Ementa

2

• _{1) Introdução.}

• _{1.1) Definições}

• _{2) Testes de Verificação.}

• 2.1) Definição

• 2.2) Tipos de testes de verificação

• _{3) Testes de Validação.}

• 3.1) Definição

• 3.2) Tipos de testes de validação

• _{4) Ferramentas automatizadas para Testes de Software}

• 4.1) Seleniiun

(3)

Introdução

3

(4)

4 1.1 – Definições – o começo

INCONSCIENTE

INCOMPETENTE

CONSCIENTE

INCOMPETENTE

CONSCIENTE

COMPETENTE

INCONSCIENTE

COMPETENTE

Pior Situação

O Começo

Aprendizado

Cultura

Pior Situação

O Começo

(5)

5 1.1 – Definições – próximos passos

Dourados – MS - 29/08/17

INCONSCIENTE

INCOMPETENTE

CONSCIENTE

INCOMPETENTE

CONSCIENTE

COMPETENTE

INCONSCIENTE

COMPETENTE

Pior Situação

O Começo

Aprendizado

Cultura

Pior Situação

O Começo

(6)

6 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

(7)

7 1.1 – Definições – quando guarantir a qualidade?

Dourados – MS - 29/08/17

Modelo

Negócios Requisito_s ModelageAnálise e m

Implemen

tação Testes deSoftware Disponibili_zação

Tempo

(8)

8 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

(9)

Testes de Verificação

9

(10)

10 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 Auditorias

Foco nas Documentações

(11)

11 2.1 – Definições – impacto das revisões

Dourados – MS - 29/08/17



Revisões de Requisitos detectam 15% dos defeitos



Revisões na Análise e Design detectam 30% dos defeitos

(12)

12 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

(13)

13 2.2 – Tipos de Testes- executando revisões

Dourados – MS - 29/08/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

(14)

14 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

(15)

15 2.2 – Tipos de Testes-

Checklist para Testes de Verificação

Dourados – MS - 29/08/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

(16)

16 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

(17)

17 2.2 – Tipos de Testes-

Checklist para Testes de Verificação

(18)

18 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

(19)

Testes de Validação

19

(20)

20 3.2 – Tipos de Testes-

Checklist para Testes de Validação

Funcional Segurança Usabilidade Performance

(21)

21 3.2 – Tipos de Testes-

Checklist para Testes de Validação

(22)

22

(23)

23 3.2 – Tipos de Testes-

Checklist para Testes de Validação

(24)

Teste de Software Caixa Branca

e Caixa Preta

(25)

25 3.1 – Definição –

Teste de Caixa Branca e Teste de Caixa Preta

Dourados – MS - 29/08/17

Caixa

(26)

26 3.1 – Definição – a

bordagem

Caixa Branca e Caixa Preta

Caixa Branca

Caixa Preta

(27)

27 3.1 – Definição –

Teste de Caixa Branca

Dourados – MS - 29/08/17

Término do

Processamento

Início do

Processamento

Caminho A

Caminho B

(28)

28 3.1 – Definição –

Teste de Caixa Preta

Resultados

Gerados

Estímulos

(29)

Categoria de Testes

29

(30)

30 3.2 – Categorias de Teste – cenários de teste

- 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

(31)

31 3.2 – Categorias de Teste – categorias

Dourados – MS - 29/08/17

- 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;

(32)

32 3.2 – Categorias de Teste – categorias

Características da Aplicação

Importância

01. Funcional

Essencial

02. 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

(33)

Casos de Teste

33

(34)

34 3.2 – Casos de Teste – Caixa Branca

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

(35)

35 3.2 – Casos de Teste – Caixa Preta

Dourados – MS - 29/08/17

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

(36)

Obtendo Casos de Teste

(37)

37 3.2 –

Obtendo Casos de Teste -Decomposição de Requisitos

Dourados – MS - 29/08/17

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.

(38)

38 3.2 –

Obtendo Casos de Teste -Análise de Documentos

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

(39)

39

Dourados – MS - 29/08/17

3.2 –

Obtendo Casos de Teste -Análise de Documentos

Cenários Positivos Casos de Testes Identificados Disponível Emprestado Restauração Refugado Análise Catalogação Doação Classificação Empréstimo Devolução Refugo Restaurar Disponibiliza Recuperação Destruição Diagrama de Estados Compra 1 2 3 6 5 4 1 2 2 3 3 4 4 2 4 5 5 6 6 1 1 Cenários Negativos 2 1 3 2 4 3 5 4 6 6 4 5

(40)

Estágios dos Testes

(41)

41 3.2 – Estágios de Teste – Alto e Baixo Nível

Dourados – MS - 29/08/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

(42)

42 3.2 – Estágios de Teste – Teste de Unidade

Unidade E Unidade H Unidade I Unidade J

Arquitetura Completa do Aplicativo

Bottom-Up

Arquitetura do Teste da Unidade E

Unidade A Unidade D Unidade _E Unidade H Unidade G Unidade F Unidade I Unidade J Unidade

(43)

43 3.2 – Estágios de Teste – Teste de Integração

Dourados – MS - 29/08/17 Integração Nível 3 Integração Nível 2 Integração Nível 1 S T S T S T S T S T S T S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S T S T S S S S S S S S S S S S S S S S S T T S Componentes de Testware Componentes de Software

(44)

44 3.2 – Estágios de Teste – Teste de Sistema

Sistema Alvo Sistema Alvo Sistema D Sistema D Sistema E Sistema E << Batch >> << Batch >> << On-Line >> << On-Line >> Sistema F Sistema F << Batch >> << Batch >> << On-Line >> << On-Line >> << Batch >> <Simulador> Sistema A <Simulador> Sistema B <Simulador> Sistema C

(45)

45 3.2 – Estágios de Teste – Teste de Aceite

Dourados – MS - 29/08/17

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 e

realizam os testes do software.

Aceite Formal

ALPHA

Teste

BETA

Clientes

Todos

Clientes são convidados a operar o software no fornecedor.

Implantação ALPHA

(46)

46 3.2 – Estágios de Teste – Teste de Ambiente

Ambiente de Desenvolviment o Ambiente Teste e Homologação Ambiente de Produção Em Teste Em

Desenvolvimento HomologaçãoEm ProduçãoEm

(47)

Ferramentas automatizadas

para Teste de Software Caixa

Preta

47

(48)

48

(49)

49 4.2 – Firebug

(50)

Página

50 https://sites.google.com/site/uemsjessica/home

(51)

Bibliografia

51

Dourados – MS - 29/08/17

- BARTIÉ, A., Garantia da Qualidade de Software. Rio de Janeiro:

Editora Campus, 2002.

(52)

#include <stdio.h>

/* Nosso Hello World! (c) */

int main (int argc, char** argv)

{

printf(“Hello World!\n”);

return (0);

}

(53)

(54)

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);

(55)

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);