TESTES DE SOFTWARE - DEINF/UFMA - Departamento de ...maria/arqan/2011-1/cap9-vvt.pdf · de Teste de...

Profa. Maria Auxiliadora

Fonte: PRESSMAN, ROGER - Engenharia de Software - 6° Edição SOMMERVILLE - Engenharia de Software - 8° Edição

TESTES DE SOFTWARE

1



Teste de software

• É uma atividade crítica na garantia de qualidade de software;

• Quatro dimensões:

– Estado do teste (“o momento”);

– Técnica do teste (“como vou testar”);

– Metas do testes (“o que tenho que testar”);

– Onde será o teste (“ambiente do teste”).

2 2



• Projetar testes que descubram sistematicamente diferentes classes de erros e façam-o com uma quantidade de tempo e esforço mínimos.

• Se a atividade de teste for conduzida com sucesso, ela descobrirá erros no software.

Objetivos da Atividade de Teste

3



• A atividade de teste não pode mostrar a ausência de bugs; ela só pode mostrar se defeitos de software estão presentes.

• Se erros graves forem encontrados com regularidade a qualidade e a confiabilidade de software são suspeitas.


4



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


5



Organização para Realização

de Teste de Software

Quando o teste se inicia há um conflito de

interesses:

Desenvolvedores: interesse em

demonstrar que o programa é isento de

erros.

Responsáveis pelos testes: interesse

em mostrar que o programa tem erros.

6



Organização para Realização

de Teste de Software

Do ponto de vista psicológico:

• Análise, Projeto e Codificação de

Software são tarefas construtivas

• Teste é tarefa destrutiva

7



• Objetivo: assegurar que o software

–Cumpra as suas especificações e atenda às necessidades dos usuários e clientes.

• Ocorrem em todo o ciclo de vida do software

–Revisões de requisitos, revisões de design, inspeções de código e teste do produto.

Verificação e Validação

8



• Validação: “Estamos construindo o produto certo?”

–O software deve atender às necessidades dos usuários.

• Verificação: “Estamos construindo o produto corretamente?”

–O software deve estar de acordo com a sua especificação.

Verificação e Validação

9



Metas do processo de Verificação e Validação

• Função de software – O nível de confiança depende de quanto o software é para uma organização.

• Expectativas de usuário – Usuários podem ter poucas expectativas em relação ao software.

10



• Ambiente de mercado – verificar o momento exato de colocar o produto no mercado ( com ou sem depuração e teste do produto).

Metas do processo de Verificação e Validação

11



Planejamento de Verificação e Validação

• Um planejamento cuidadoso é necessário para obter o melhor das inspeções e dos testes e para controlar os custos do processo de verificação e validação.

• O planejando de V&V deve se iniciar no começo do processo de desenvolvimento.

12



Especificação de requisitos

Teste de unicidade e de módulo

Plano de teste de aceitação

Especificação de sistema

Projeto de sistema

Projeto detalhado

Operação

Teste de aceitação

Teste de integração do sistema

Teste de integração

do subsistema

Plano de teste de integração

de sistema

Plano de teste de integração de subsistema

Planejamento de Verificação e Validação

13



• Fatores de Qualidade de Revisão –Relacionados com a manutenção,

evolução e avaliação do software.

• Fatores de Qualidade de Transição –Relacionados com a instalação,

reutilização e interação com outros produtos.

O que deve ser verificado e validado?

14



• Inspeções de software

–(V & V estática)

• Testes de software

–(V & V dinâmica)

Técnicas de V & V

15



• Interessadas na análise da

representação estática do sistema para

descobrir problemas

Pode ser suplementado por

ferramentas baseadas em documentos

e análise de códigos.

Inspeções de Software

16



Teste de Inspeção

17



• Revisões cujo objetivo é a detecção de defeitos no programa.

• Principal meta DESCOBERTA de defeito (não correção).

•

• Defeitos podem ser erros lógicos, anomalias no código que poderia indicar uma condição errônea.

Inspeções de Programas

18



• Defeitos nos dados:

–Todas as variáveis de programa são iniciadas antes de seus valores serem utilizados?

–Todas as constantes foram denominadas?

–Existe alguma possibilidade de overflow de buffer (limite de vetores)?

Checagem de Inspeções

19



• Defeitos de controle:

– Para cada condição condicional a condição está correta?

– As declarações compostas estão corretamente entre parênteses?


20



• Defeitos de entrada e saída

–Todas as variáveis de entrada são utilizadas?

–Todas as variáveis de saída têm um valor designado antes de saírem?


21



• Defeitos de interface

–Todas as chamadas de funções e métodos têm o número correto de parâmetros?

–Os parâmetros estão em ordem corretas?


22



• Defeito de gerenciamento de armazenamento

–Se o armazenamento dinâmico é utilizado, o espaço foi alocado corretamente?

–O espaço é explicitamente liberado, depois que não é mais necessário?


23



Teste de software (dinâmica)

24 24



• Objetivo: Avaliar a possibilidade de uso do sistema

• Quem faz: Cliente ou usuário final

• O que é testado: Funções principais, documentação e procedimentos

• Quando termina: Em geral, quando o usuário se sente a vontade, ou quando o teste proposto dá bom resultado.

Teste de Validação - escopo

25



• Um teste próspero é um teste que descobre um ou mais erros.

• Elaboração de casos de testes baseados na especificação funcional –Dados de entradas. –Comportamento esperado.

Teste de Programa

26



• Podem ser classificados

–Quanto ao método: defeitos e estatísticos.

–Quanto ao escopo: unicidade, integração, sistema e aceitação.

Teste de Programa

27



• Testes de defeitos

– Tem por objetivo encontrar defeitos – inconsistências entre o programa e a sua especificação.

– Verifica a correção – conhecido também por testes de correção.

– Normalmente realizados com protótipos funcionais.

Tipos de Testes – (Método)

28



• Testes estatísticos – Utilizados para avaliar o

desempenho e a confiabilidade – checar como ele trabalha nas condições operacionais

• Exemplos de medições: –Número de falhas observadas –Tempos de resposta –Tempos de execução

Tipos de Testes – (Método)

29



Teste de Programa

Fase de

Validação

Categorias de Testes

Aplicadas

Características da Fase de

Validação

Teste de

Baixo Nível

Teste de

Unidade

Estrutura Interna

Funcionalidade

Usabilidade

Segurança

Estratégia caixa branca e

caixa preta.

Testar partes do software.

Requer conhecimento da

estrutura interna.

Executada pelo

desenvolvedor ou

profissional de teste.

Teste de

Integração

Interfaces

Dependência

entre

Componentes

Estratégia de caixa branca e

caixa preta.

Testa integrações entre

partes de software.

Requer conhecimento da

arquitetura interna do

software.

Executada pelo

desenvolvedor ou

profissional de teste. 30



Teste de Programa

Fase de

Validação

Categorias de Testes

Aplicadas

Características da Fase de

Validação

Teste de

Alto Nível

Teste de

sistema

Funcionais

Não Funcionais

o Performance

o Instalação

o Recuperação

o Carga

Estratégia de caixa preta.

Os testes são aplicados no

software como todo.

Não requer conhecimento da

estrutura interna do

software.

Requer ambiente muito

semelhante ao da produção.

Deves ser executada por um

grupo de teste

independente.

31



Esquema

Tipos de Unicidade

32



Tipos de Unicidade

33

• É o processo de teste de componentes

individuais isoladamente.

• As unidades podem ser:

Funções individuais ou métodos dentro de um objeto Classes de objetos com vários atributos e métodos Componentes compostos com interfaces definidas

usados para acessar suas funções.



Tipos de Unicidade

34



• Concentra-se no projeto e na construção da arquitetura de software.

• Conhecidos como testes em ponto grande.

• Os componentes são integrados e o conjunto maior é testado – módulo e subsistemas.

Testes de Integração

35



• Tipos de interfaces

Interfaces de parâmetro - Dados passados de um método ou

procedimento para o outro.

Interfaces de memória compartilhada - Blocos de memória são

compartilhados entre os procedimentos ou funções.

Interfaces de procedimento - Subsistemas sintetizam um conjunto

de procedimentos para serem chamados por outros subsistemas.

Interfaces de passagem de mensagem - Subsistemas solicitam

serviços de outros subsistemas.


36



• Quem faz: Geralmente o programador.

• O que é testado: A integração entre os módulos.

• Quando termina: Quando o programador verifica que a interligação entre os módulos se encontra bem definida.


37



• Não-Incremental: As unidades são combinadas e o programa completo é testado como um todo.

• Incremental: Combina o módulo seguinte a ser testado com o conjunto de módulos já testados, existem alguns tipos: – Integração Top-down.

– Integração Bottom-up.


38



• Módulos são integrados de cima para baixo, partindo-se do módulo principal.

• Pode ser realizada, de duas maneiras:

−por profundidade (depth first)

−por largura (breadth first)

Integração Top-down

39



Integração Top-down

40



Integração Bottom-up

• Início da construção e dos testes com módulos atômicos (localizados no nível mais baixo da estrutura do sistema).

• Quando os módulos de níveis superiores

vão ser testados, os módulos subordinados já estão prontos e portanto, não se torna necessária a criação de stubs.

41



Mb

D1 D2 D3

Ma

Mc

Cluster 1

Cluster 2

Cluster 3

Integração Bottom-up

42



• Integração Top-down:

– Vantagem: Testar logo no início as funções principais do software.

– Desvantagem: necessidade de simuladores.

• Integração Bottom-up:

– Vantagem: permite que as unidades mais básicas sejam testadas mais cedo.

– Desvantagem: O módulo principal não existe até que todos os módulos estiverem testados.

Testes de Integração Vantagens e desvantagens

43



• Verificar se as funções estão de acordo com a especificação e se todos os elementos do sistema combinam-se adequadamente.

• Quem faz: Líder do projeto ou grupo de teste;

• O que é testado: Necessidades técnicas e funcionais do sistema. Interfaces do sistema;

Teste de Sistema

44



• Quando termina: Em geral, quando a maioria das necessidades é atendida, permanecendo poucos erros importantes;

• Recursos extras: Biblioteca de casos de testes. Geradores, comparadores e simuladores de teste em massa.

Teste de Sistema

45



• Envolve uma série de diferentes testes, cujo propósito primordial é pôr completamente à prova o sistema baseado em computador.

• Se divide em quatro testes:

–Teste de Recuperação;

–Teste de Estresse;

–Teste de Desempenho;

–Teste de Segurança.

Teste de Sistema

46



• Teste de Recuperação

−É um teste de sistema que força o software a falhar de diversas maneiras e verifica se a recuperação é adequadamente executada.

Teste de Sistema

47



• Teste de Estresse

–Confronta os programas com situações anormais de frequência, volume ou recursos em quantidade.

–Pode ser utilizada uma lista com situações padrão de provocação de “estresse do sistema”.

Teste de Sistema

48



• Teste de Desempenho

−Testa o tempo de resposta do sistema e é aplicado geralmente para sistemas de tempo real.

−Preocupa-se com o rendimento, tempo de resposta e capacidade

( especialmente a capacidade do banco de dados.)

Teste de Sistema

49



• Teste de Segurança

– Tenta verificar se todos os mecanismos de proteção embutidos num sistema o protegerão, de fato, de acessos indevidos.

– A estratégia de teste deve ser feita por programadores que não desenvolveram o software.

– Os testadores devem tentar invadir o sistema de várias formas: obtenção ilegal de senhas, desarme do sistema e outros.

Teste de Sistema

50



• Objetivo: Avaliar a possibilidade de uso do sistema;

• Quem faz: Cliente ou usuário final;

• O que é testado: Funções principais, documentação e procedimentos;

• Quando termina: Em geral, quando o usuário se sente a vontade, ou quando o teste proposto dá bom resultado.

Teste de Aceitação

51



Revisão da configuração


52



• Tipos:

– Alfa: É feito por um cliente nas instalações do desenvolvedor. O software é usado num ambiente controlado com o desenvolvedor "olhando sobre os ombros“ do usuário e registrando erros e problemas de uso.


53



• Tipos....

− Beta: É realizado nas instalações do cliente pelo usuário final do software. O desenvolvedor não está presente, e o cliente registra os problemas que são encontrados e relata-os ao desenvolvedor posteriormente.


54



– Oferece uma abordagem sistemática ao teste; − É 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.

Projeto de Casos de Teste

55



• Teste de Caixa Preta (teste funcional) • Teste de Caixa Branca (teste estrutural) Teste de Caminho Básico

–Caminho Independente –Complexidade Ciclomática

Teste de Estrutura de Controle −Teste de Condição −Teste de Fluxo de Dados −Teste de Laços

Teste no contexto de OO

Projeto de Casos de Teste

56



• O programa é uma caixa preta cujo comportamento é determinado estudando-se as suas entradas e saídas.

• Os casos de testes são derivados da especificação funcional.

• A escolha dos dados de entrada podem ser feitas com várias técnicas: – Partição de domínio – Análise de valor limite

Teste Funcional (caixa preta)

57



• Envolve dois passos principais:

–Identificar as funções que o software deve realizar (especificação dos requisitos)

–Criar casos de teste capazes de checar se essas funções estão sendo executadas corretamente.


58



Entradas que provocam comportamento anômalo

I

e

O e

Sistema

Entrada de dados de teste

Saída dos resultados de teste

Saídas que revelam a presença de defeitos


59



• Problemas:

−Dificuldade em quantificar a atividade de teste: não se pode garantir que partes essenciais ou críticas do software foram executadas.

−Dificuldade de automatização.


60



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

• Exercita as estruturas de dados internas para garantir a sua validade;

Teste estrutural (caixa branca)

61



• Executa todos os laços em suas fronteiras;

• Exercita todas as decisões lógicas para valores falsos ou verdadeiros.


62



Código de componente

Saídas do teste

Dados de teste

testa Deriva


63



Teste de Caminho Básico

O teste 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.

64



Teste de Caminho Básico

65



Fluxograma e Grafo de Fluxo

7 8

4

5

6

3

1

2

11

9 10

Fluxograma Grafo de fluxo

2

3

4, 5 6

7 8

10 9

11

1

66



Teste de software

Atividades de Teste

Avaliação

Depuração

Modelo de Confiabilidade

Configuração de Software

Configuração de Teste

Resultados dos Testes

Resultados Esperados

Dados da Taxa de Erros

Erros

Confiabilidade Prevista

Correções

Esquema

67



Ferramentas de Automatização

• Uma ferramenta de teste reduz a intervenção humana nos resultados obtidos, aumentando a qualidade e a produtividade da atividade de teste. Influencia diretamente a confiabilidade do software testado.

68



Tipos de Ferramentas

• Estáticas: verificam portabilidade, estilo e são independentes da qualidade dos casos de teste.

• Dinâmico – Monitoram a execução do programa. Adiciona código a um programa para contar o número de vezes que cada declaração foi executada.

• Simulador – simulam a máquina em que o programa deve ser executado.

69

TESTES DE SOFTWARE - DEINF/UFMA - Departamento de ...maria/arqan/2011-1/cap9-vvt.pdf · de Teste de...

Documents

Transcript of TESTES DE SOFTWARE - DEINF/UFMA - Departamento de ...maria/arqan/2011-1/cap9-vvt.pdf · de Teste de...