Teste de Software[1]

Extraído de :PRESSMAN, Roger. Engenharia de Software.

2/34

Técnicas de Teste de SoftwareTécnicas de Teste de Software

Objetivo

Objetivo : projetar testes que descubram sistematicamente diferentes classes de errosclasses de erros e façam-no com uma quantidade de tempo e esforço mínimos.

A atividade de teste não pode mostrar a ausência de A atividade de teste não pode mostrar a ausência de falhas, ela só pode mostrar se defeitos de software falhas, ela só pode mostrar se defeitos de software

estão presentesestão presentesSe erros graves forem encontrados com regularidade a

qualidade e a confiabilidade de software são suspeitas

Se erros facilmente corrigíveis forem encontrados a qualidade e a confiabilidade do software estão aceitáveis ou os testes são inadequados para revelar erros graves.

Se não for encontrado erro, a configuração de teste não foi suficientemente elaborada e erros estão escondidos no software

3/34


Objetivo

1. A atividade de Teste é o processo de executar um programa com a intenção de descobrir um erro

2. Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto

3. Um teste bem-sucedido é aquele que revela um erro ainda não descoberto

4/34


Objetivo

Atividadesde Teste

Avaliação

Depuração

Modelo deConfiabilidade

Configuração de Software- Especificação de Requisitos- Especificação de Projeto- Código Fonte

ResultadosEsperados

Dados deTaxas deErros

Erros

ConfiabilidadePrevista

Configuração de Teste- Plano e Procedimento de Teste- Ferramentas de Teste- Casos de Teste

Resultadosdos Testes

5/34


Projeto de Casos de Teste

Métodos de Projeto de Casos de TesteProjeto de Casos de Teste oferecem uma abordagem sistemática ao teste e um mecanismo que ajuda a garantir a mais

alta probabilidade de revelar erros no software com uma quantidade mínima de tempo e esforço.

Abordagens de Teste:

Caixa Branca Caixa Preta

6/34



Teste de Caixa PretaTeste de Caixa Preta refere-se aos testes que são realizados nas interfaces do

software são usados para demonstrar

1. que as funções dos softwares são operacionais; 2. que a entrada é adequadamente aceita e a saída é

corretamente produzida; 3. que a integridade das informações externas é mantida

examina aspectos do sistema sem se preocupar muito com a estrutura lógica interna do software

7/34



Teste de Caixa BrancaTeste de Caixa Brancabaseia-se num minuncioso exame dos detalhes procedimentaiso estado do programa pode ser examinado em vários pontos para

determinar se o estado esperado ou estabelecido corresponde ao estado real

são testados os caminhos lógicos através do software, fornecendo-se casos de teste que põem à prova conjuntos específicos de condições e/ou laços

8/34



um teste de Caixa BrancaCaixa Branca efetuado de forma muito cuidadosa levaria a “100% de programas corretos”?

Testes exaustivosTestes exaustivos apresentam certos problemas logísticos. Mesmo para pequenos programas, o número de caminhos lógicos possíveis pode ser muito grande !!!

9/34


Teste de Caixa Branca

É um método de projeto de casos de teste que usa a estrutura de controle do projeto procedimental para derivar casos de testecasos de teste.

Podem ser derivados casos de testes que:

1. Garantam que todos os caminhos independentescaminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez

2. Exercitem todos as decisões lógicas para valores falsosfalsos ou verdadeirosverdadeiros

3. Executem todos os laçoslaços em suas fronteiras e dentro de seus limites operacionais

4. Exercitem as estruturas de dados internasestruturas de dados internas para garantir a sua validade

Caixa Branca

10/34


Teste de Caixa Branca - Teste de Caminho BásicoTeste de Caminho BásicoO Método de Caminho BásicoMétodo de Caminho Básico possibilita que o projetista do caso

de teste derive uma medida de complexidade lógica de um projeto procedimental e use essa medida como guia para definir

um conjunto básico de caminhos de execução

GRAFO de Fluxo ou GRAFO de PROGRAMA:GRAFO de Fluxo ou GRAFO de PROGRAMA: É uma notação para representar o fluxo de controle. Cada construção estruturada tem um símbolo de grafo correspondente.

seqüênciaseqüência sese enquantoenquanto repetir atérepetir até

Caixa Branca

sese

11/34


Nós Predicativos

Estrutura CASEEstrutura CASE

decomposta

Teste de Caixa Branca - Teste de Caminho BásicoTeste de Caminho Básico

A estrutura CasoCaso deve ser decomposta em estruturas SeSe

12

CC

2CC

1

Caixa Branca

12/34



GRAFO de FluxoGRAFO de Fluxo1

2,3

6

7 8

9

4,5

10

11

Conjunto BásicoConjunto BásicoCaminho 1 : 1-11

Caminho 2 : 1-2-3-4-5-10-1-11

Caminho 3 : 1-2-3-6-8-9-10-1-11

Caminho 4 : 1-2-3-6-7-9-10-1-11

Caixa Branca

13/34



Complexidade CiclomáticaComplexidade CiclomáticaÉ uma métrica de software que proporciona uma medida

quantitativa da complexidade lógica de um programa.

Quando usado no contexto do método de teste de caminho básico, o valor computado da complexidade ciclomática define o número de caminhos independentescaminhos independentes do conjunto básico de um programa e oferece um limitelimite máximomáximo para o número de testes que deve ser realizado para garantir que todas as instruções sejam executadas pelo menos uma vez.

Caixa Branca

14/34



Complexidade CiclomáticaComplexidade CiclomáticaÉ computada numa das 3 formas seguintes:

1. O número de regiões do gráfico de fluxo

2. V(G) = E - N + 2 , onde E é o número de ramos do grafo e N o número de nós do grafo de fluxo G

3. V(G) = P + 1 , onde P é o número de nós predicativos (nós que contém uma condição) contido no grafo de fluxo G.

Caixa Branca

15/34



GRAFO de FluxoGRAFO de Fluxo1

2,3

6

7 8

9

4,5

10

11

Complexidade CiclomáticaComplexidade Ciclomática

O grafo de fluxo tem 4 regiõesV(G) = 11 ramos - 9 nós + 2 = 4V(G) = 3 nós predicativos +1 = 4

Complexidade Ciclomática do grafo de fluxo é igual a 4

1

2,3

6

Caixa Branca

16/34

Técnicas de Teste de SoftwareTécnicas de Teste de SoftwareCaixa Branca


Derivando casos de testes - Passos do MétodoDerivando casos de testes - Passos do Método1. Usando o projeto ou o código como base

trace um grafos de fluxo correspondenteProcedimento MAIOR (A:Vetor; T:inteiro; var MAX: inteiro);variáveis I,M : inteiro;Início1. M <- A[1];2. I <- 2;3. Enquanto I < T faça4. Se A[I] > M5. Então M <- A[I]6. I <- I + 17. Senão I <- I + 18. FimSe9. FimEnquanto10. Max <- MFim do Procedimento

7 5,6

8

9

10

1,2

3

4

17/34



Derivando casos de testes - Passos do MétodoDerivando casos de testes - Passos do Método

2. Determine a Complexidade Ciclométrica do grafo de fluxo resultante

7 5,6

8

9

10

1,2

3

4

Complexidade CiclomáticaComplexidade Ciclomática

O grafo de fluxo tem 3 regiõesV(G) = 10 ramos - 9 nós + 2 = 3V(G) = 2 nós predicativos + 1 = 3

Complexidade Ciclomática do grafo de fluxo é igual a 3

4

3

18/34



Derivando casos de testes - Passos do MétodoDerivando casos de testes - Passos do Método

3. Determine um conjunto básico de caminhos linearmente independentes

7 5,6

8

9

10

1,2

3

4

CaminhosCaminhos

Caminho 1 : 1-2-3-10Caminho 2 : 1-2-3-4-5-6-8-9-3-10Caminho 3 : 1-2-3-4-7-8-9-3-10

4

3

19/34



Derivando casos de testes - Passos do MétodoDerivando casos de testes - Passos do Método4. Prepare os casos de teste que forcem a execução

de cada caminho no conjunto básico

CaminhosCaminhosCaminho 1 : 1-2-9-3-10

Caminho 2 : 1-2-3-4-5-6-8-9-3-10

Caminho 3 : 1-2-3-4-7-8-9-3-10

Procedimento MAIOR (A:Vetor; T:inteiro; var MAX: inteiro);variáveis I,M : inteiro;Início1. M <- A[1];2. I <- 2;3. Enquanto I < T faça4. Se A[I] > M5. Então M <- A[I]6. I <- I + 17. Senão I <- I + 18. FimSe9. FimEnquanto10. Max <- MFim do Procedimento

A = (1,3) - T = 0 Result : MAX = 1

A = (1,3) - T = 2 Result : MAX = 3

A = (3,1) - T = 2 Result : MAX = 3

Caixa Branca

20/34


Teste de Caixa Preta

Concentra-se nos requisitos funcionais requisitos funcionais do software

O teste de Caixa Preta procura descobrir erros nas seguintes categorias:

1. Funções incorretas ou ausentes

2. Erros de interface

3. Erros nas estruturas de dados ou no acesso a bancos de dados externos

4. Erros de desempenho

5. Erros de inicialização e término

Caixa Preta

21/34



Testes são projetados para responder às seguintes perguntas:

Como a validade funcional é testada?Quais classes de entrada constituirão bons casos de teste?O sistema é particularmente sensível a certos valores de entrada?Como as fronteiras de uma classe de dados são isoladas?Quais índices de dados e volumes de dados o sistema pode tolerar?Que efeito terão combinações específicas de dados sobre operação

do sistema?

Caixa Preta

22/34



Particionamento de EquivalênciaParticionamento de Equivalência

O Particionamento de EquivalênciaParticionamento de Equivalência é um método de teste de caixa preta que divide o domínio de entrada de um programa em classes de

dados a partir das quais os casos de teste podem ser derivados.

Caixa Preta

Uma classe de equivalência representa um conjunto de estados válidos ou inválidos para condições de entrada

As classes de equivalência podem ser definidas de acordo com as seguintes diretrizes:

1 - Se uma condição especificar um intervalointervalo, uma classe de equivalência válida e duas classes de equivalência inválidas são definidas

23/34



Particionamento de EquivalênciaParticionamento de Equivalência

Caixa Preta

As classes de equivalência podem ser definidas de acordo com as seguintes diretrizes:

2 - Se uma condição especificar um valor específicovalor específico, uma classe de equivalência válida e duas classes de equivalência inválidas são definidas3 - Se uma condição especificar um membro de um conjuntomembro de um conjunto, uma classe de equivalência válida e uma classe de equivalência inválida são definidas4 - Se uma condição de entrada for booleanabooleana, uma classe de equivalência válida e uma classe de equivalência inválida são definidas

24/34


Validação x VerificaçãoValidação x Verificação

ValidaçãoValidação: Corresponde à avaliação da corretude do software em função dos requisitos definidos. (Qualidade do Produto)

VerificaçãoVerificação: Corresponde à avaliação da corretude do processo de construção do software. (Qualidade de Desenvolvimento)

Categorias de Casos de Teste

25/34


Categorias de Casos de Teste*

1 - Testes de Cobertura de Instruções1 - Testes de Cobertura de InstruçõesConfirmar se cada instrução de procedimento em um programa foi testada pelo menos uma vez. Podem ser usadas ferramentas automatizadas para relatar diversas condições de cobertura, como o grau em que cada instrução de procedimento do programa foi testado.

* Retirado de :FOURNIER, Roger. Guia prático para desenvolvimento e manutenção

de sistemas estruturados. São Paulo:Makron Books, 1994.

26/34



2 - Testes de Cobertura de Desvios2 - Testes de Cobertura de DesviosConfirmar se cada condição de desvio de uma instrução de decisão foi testada pelo menos uma vez.

3 - Testes de Cobertura de 3 - Testes de Cobertura de LoopsLoopsConfirmar condições usadas para iniciar e encerrar um loop em um programa.

4 - Testes de Amostra de Valores4 - Testes de Amostra de ValoresTestar condições de entrada de um programa, fornecendo amostras de dados de teste que se encaixem em uma faixa de valores que seria esperada em uma situação normal. Esse tipo de teste é usado quando não é prático cobrir todas as situações possíveis devido à imensa quantidade de possibilidades. Esses testes são normalmente utilizados para verificar se o programa pode lidar com dados normais.

27/34



5 - Testes de Cobertura de Valores Limites5 - Testes de Cobertura de Valores LimitesConfirmar condições de entrada/saída de um programa, usando casos de teste compostos por valores mínimo, máximo e fora dos limites.

6 - Testes de Interface do Programa6 - Testes de Interface do ProgramaConfirmar as interfaces entre módulos e entre funções de um programa. Verificando se os dados e os parâmetros de controle são passados apropriadamente entre módulos de um programa.

7- Testes de Gerenciamento de Arquivos7- Testes de Gerenciamento de ArquivosTestar condições normais e anormais de gerenciamento de arquivos. Por exemplo, um arquivo vazio ou um arquivo que contenha somente um registro pode ser criado para verificar como o programa lida com essas situações.

28/34



8 - Testes de Mensagens de Erro8 - Testes de Mensagens de ErroPara testar condições de erro conhecidas que devem ser gerenciadas pelo programa. A precisão e inteireza das mensagens de erro também podem ser verificadas enquanto o programa é testado para determinar se ele pode lidar com transações inválidas

9 - Testes de Propensão a Erros9 - Testes de Propensão a ErrosTestar o programa usando dados de teste inválidos ou com erros. Por exemplo, tipos de dados incompatíveis com os campos de entrada.

10 - Testes de Volume10 - Testes de VolumeConfirmar que o sistema não consegue lidar com o volume de dados especificado originalmente nos requisitos dos usuários. Testes de volume podem facilmente se tornar caros e complexos quando grandes arquivos estão envolvidos.

29/34



11 - Testes de Desempenho11 - Testes de DesempenhoConfirmar que o sistema não opera de acordo com os requisitos de tempo de resposta, taxas de processamento e tempo de processamento/execução previstos.

12 - Testes de Esforço12 - Testes de EsforçoConfirmar que o sistema não pode lidar com situações inesperadas. Normalmente, esses testes são executados em sistemas on-line ou em sistemas de tempo real, onde volumes incomuns de dados podem subitamente fazer com que eles entrem em pane.

13 - Testes de Cópias de Segurança, Recuperação, 13 - Testes de Cópias de Segurança, Recuperação, Reorganização e ReinícioReorganização e ReinícioConfirmar que os procedimentos de cópia de segurança, recuperação, reorganização e reinício não falharão quando o sistema falhar em função de falhas de hardware e software.

30/34



14 - Testes de Uso14 - Testes de UsoConfirmar que as interfaces homem-máquina do programa são fáceis de entender e usar do ponto de vista das pessoas. As características ergonômicas de um sistema podem mudar em função da pessoa que manipula o sistema.

15 - Testes de Documentação15 - Testes de DocumentaçãoDemonstrar que o material de documentação dos usuários e de sistemas descreve adequadamente as condições de trabalho do sistema.

16 - Testes de Segurança16 - Testes de SegurançaDemonstrar que o sistema não pode ser invadido, tentando contornar as medidas e recursos de segurança projetados para evitar isso.

31/34



17 - Testes de Procedimentos Manuais17 - Testes de Procedimentos ManuaisDemonstrar que os procedimentos manuais que coexistem com a parte automatizada não apresentam erros.

18 - Testes de Armazenamento18 - Testes de ArmazenamentoDemonstrar que os requisitos de armazenamento de dados do sistema não foram plenamente satisfeitos.

19 - Testes de Compatibilidade19 - Testes de CompatibilidadeDemonstrar que as configurações de hardware/software/rede que serão usados no ambiente de produção não são totalmente compatíveis no uso conjunto.

32/34



20 - Testes de Interface do Sistema20 - Testes de Interface do SistemaDemonstrar que as conexões estabelecidas entre esse sistema e outros sistemas não funcionam adequadamente

21 - Testes de Controle21 - Testes de ControleDemonstrar que os recursos de controle embutidos no sistema não funcionam adequadamente. Por exemplo as trilhas de auditoria.

22 - Testes de Conversão22 - Testes de ConversãoDemonstrar que os procedimentos manuais ou automatizados de conversão não funcionam adequadamente.

23 - Testes de Diálogos de Telas23 - Testes de Diálogos de TelasDemonstrar que os diálogos de telas do sistema não funcionam adequadamente ou são incompletos.

33/34



24 - Testes de Instabilidade24 - Testes de InstabilidadeDemonstrar que o sistema não pode ser instalado em diferentes localizações geográficas devido a defeitos identificados durante a instalação.

25 - Testes de Funções25 - Testes de FunçõesDemonstrar que as funções do sistema não correspondem às necessidades de negócio dos usuários.

26 - Testes de Manutenção26 - Testes de ManutençãoDemonstrar que o sistema dificilmente será mantido ou melhorado quando em produção.

27 - Testes de Recuperação de Desastres27 - Testes de Recuperação de DesastresDemonstrar que os procedimentos para resolver uma eventual situação de recuperação de desastres não funcionam.

34/34



28 - Testes de Integridade28 - Testes de IntegridadeDemonstrar que os valores de entrada do sistema causam algum tipo de falha de integridade no banco de dados. Exemplo falha na integridade relacional

29 - Testes de Acesso29 - Testes de AcessoDemonstrar que o sistema não suporta múltiplos acessos .em um ambiente multi-usuário ou de acesso remoto.

Teste de Software[1]

Documents

Transcript of Teste de Software[1]