Teste de Software - facom.ufu.brbacala/ES/16-Introducao aos Testes.pdf · •Teste de software. Relacionado ao exercício e à observação do comportamento do produto ... Teste e

Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala

Teste de Software: introdução

http://www.facom.ufu.br/~bacala


Verificação vs Validação

• Verificação: “Estamos construindo o produto corretamente?” • O software deve estar de acordo com sua especificação.

• Validação: “Estamos construindo o produto certo?”. • O software deve fazer o que o usuário realmente deseja.

20

16

2



O processo V & V

• Deve ser aplicado a cada estágio do desenvolvimento de software

– Vale tanto para verificação quanto validação

• Tem dois objetivos principais:

– Descobrir problemas em um sistema;

• Problema = sistema que não satisfaz sua especificação

– Avaliar se o sistema é útil e usável ou não em uma situação operacional.

20

16

3



Objetivos de V& V

• Verificação e validação devem estabelecer confiança de que o software é adequado ao seu propósito.

• Isto NÃO significa completamente livre de defeitos.

• Ao invés disso, deve ser bom o suficiente para seu uso pretendido

• Tipo de uso determinará o grau de confiança necessário.

20

16

4



V & V estática e dinâmica

• Inspeções de software. Análise de representações estáticas do sistema com o objetivo de descobrir problemas (verificação estática) – Pode ser suplementado por um documento baseado em

ferramenta e análise de código.

• Teste de software. Relacionado ao exercício e à observação do comportamento do produto (verificação dinâmica) – O sistema é executado com dados de teste e seu

comportamento operacional é observado.

• Outras técnicas: análise dinâmica, prototipação, entrevistas, cenários

20

16

5



V & V estática e dinâmica

20

16

6



O que é Teste?

• Conjunto de atividades e técnicas relacionadas com a procura de erros em um programa

20

16

7

Testes procura erros em conjunto de

possíveis execuções do programa.



Teste em Perspectiva

• Prova de teorema

• Prova propriedades complexas,

• Requer muito esforço humano.

• Análise estática

• Prova propriedades simples;

• Pode apresentar alarmes falso.

• Automático.

• Teste

• Não prova corretude e

• não é inteiramente automático!

20

16

8



Limitações de Prova de Teorema

• Requer conhecimento de um expert

• Processo manual

• tedioso e passível de erro

20

16

9



Limitações de Análise Estática

• Provar propriedades de forma automática é, em geral, indecidível!

• Eficaz apenas quando

• Propriedades de verificação são simples

• Variáveis não inicializadas, erros de tipo, etc.

• Programas (/ modelos) são simples

• Ausência de loop e recursão, ausência de heap, etc.

20

16

10



Citação de Dijkstra

• “Testing can never demonstrate the absence of errors in software, only their presence.” -- E.W.Dijkstra

20

16

11

Principal limitação de testes é

incompletude: é possível que teste

não encontre um erro latente.



Testes é incompleto, porém...

• Rápida implantação

• Documenta intenções e designs

• Capaz de encontrar erros complexos em programas complexos

• Erros complexos: memory leak, deadlock

20

16

12



Definição: Teste (artefato)‏

• “A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement” [IEEE, do178b]

20

16

13



Exemplo

public class Customer {

String getName() {…}

}

public class Bank{

static Bank createBank() {…}

Customer createCustomer(String name) {…}

}

20

16

14



Exemplo



}

public class Bank{



}

Bank bank = Bank.createBank();

String name = “customer1“;

Customer cust = bank.createCustomer(name);

Assert.assertEquals(name, cust.getName());

20

16

15



Exemplo



}

public class Bank{



}





Entrada e resultado esperado:

20

16

16



Exemplo



}

public class Bank{



Customer search(String name) {…}

}



Customer cust = bank.search(name);

if (cust == null) {



}

Condições de execução:

20

16

17



Terminologia: Falta e Falha

• IEEE STD. 982.2-1988 (http://standards.ieee.org/)‏

– problema :‏Fault (falta, bug ou defeito)‏

– Failure (falha, ou erro)‏: manifestação do problema

• Mais detalhes…

– Software Metrics and Reliability [Rosenberg et al., ISSRE’98]

20

16

18


http://standards.ieee.org/


Quiz: Localize falta e falha

// pre condicao: v != null

public static void sort(int[] v) {

for (int i = 0; i <= v.length; i++) {

…v[i] …

}

}

20

16

19



Quiz: Localize falta e falha

// pre condicao: v != null

public static void sort(int[] v) {

for (int i = 0; i <= v.length; i++) {

…v[i] …

}

} defeito

manifestação do defeito

20

16

20



Teste e Depuração

• Teste é atividade de localizar falhas!

• Depuração é atividade de localizar faltas!

Teste e Depuração são atividades

complementares

20

16

21



Teste e Depuração

• Teste é atividade de localizar falhas!

• Depuração é atividade de localizar faltas!

• No exemplo anterior:

– Atividade de teste localiza erro no uso de v[i] no corpo do loop de sort.

– Depuração localiza o defeito na condição de parada do loop i <= v.length

20

16

22



Teste de sort

public class SortTest{

public static void main(String[] args) {

sort(new int[]{});

}

}

20

16

23



Terminologia: suíte e regressão

• Suíte de testes é o mesmo que conjunto de testes

• Regressão é o evento de uma falha em um teste que costumava passar

Rodar continuamente a suíte de regressão

ajuda a antecipar correção de bugs!

20

16

24


Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala 25

Alguns dados estatísticos (1)‏

• Beizer [1990] estimou que testes toma 30% a 90% do custo de desenvolvimento

• Santhanan and Hailpern [2002] relata que de 50 a 75% do custo de desenvolvimento envolve teste e depuração

20

16

25



Alguns dados estatísticos (2)‏

• O instituto americano de padrões e tecnologia (NIST) [2002] estima que $59.2bi é o custo da infra-estrutura inadequada de teste. 2

01

6

26



Motivação

• Existe grande possibilidade de injeção de falhas humanas no processo de desenvolvimento de software

• Os custos associados às falhas de software justificam um processo de testes cuidadoso e bem planejado

20

16

27



Motivação

• U$59.500.000.000,00 foi o custo das falhas em software

nos EUA, apenas em 2002.

• U$22.200.000.000,00 em economia, caso a infra-

estrutura para testes fosse melhor 20

16

28



Motivação

• Mars Climate Orbiter

• Objetivo

– Enviar sinais a partir de Marte, após seu pouso no planeta

• Desastre – Chocou-se com o planeta

• Motivo

– Bug no software responsável pela conversão de medidas

• Prejuízo

– 165 milhões de dólares

20

16

29



Motivação

• Airbus Airbus 320

• Desastre

– USS Vicennes derrubou um Airbus 320 em 1988

• Motivo

– Bug no software no software de reconhecimento

confundindo o avião com um F14

• Prejuízo

– 290 mortes

20

16

30



Motivação

• Máquina de Terapia Radiotiva

• Desastre

– Overdose em pacientes sob tratamento

• Motivo – Inabilidade em gerenciar certas condições de

disputa

• Prejuízo

– Morte de 2 pessoas

– 6 outras lesionadas

20

16

31



Motivação

• London Ambulance Service

• Desastre – Serviço auxiliado por computador falhou nos dias 26

e 27 de novembro de 1992, gerando várias falhas, como o envio de 2 ambulâncias para o mesmo destino, envio de uma ambulância para um local estando outras mais próximas, etc

• Motivo – Tudo indica que o problema estava relacionado a alta

carga de emergências durante o período.

• Prejuízo – 20 mortes

20

16

32



Motivação

• Airbus A300 China Air Lines

• Desastre

– Avião caiu em 1994

• Motivo

– Foi feita uma investigação e, dentre as

recomendações, aconselharam mudanças nos

softwares de controle

• Prejuízo

– 264 mortes

20

16

33



Motivação

• Se a indústria automobilística tivesse se desenvolvido como a indústria do software, nós teríamos carros por U$25, fazendo 5000 milhas com um galão de combustível.

• Porém, esse carro iria “quebrar” duas vezes por dia, sem um motivo aparente, e quando você solicitasse assistência junto às concessionárias eles iriam dizer para você reinstalar o motor.

20

16

34



Motivação para Teste

20

16

35



20

16

36


As falhas causam

prejuízos

financeiros

As falhas causam a

perda de confiança

do cliente



20

16

37

Por que algumas empresas não testam?

Teste é um

processo

caro

Dificuldade em

implantar um

processo de teste

Desconhecem

técnicas de

teste

adequadas

Desconhecem

a relação

custo/benefício

Só se preocupam

com teste na fase

final do projeto




• Segundo pesquisas do SEI ( Software Engineering Institute):

• 30% dos projetos são cancelados antes de

serem finalizados

• 70% dos projetos falham nas entregas das

funcionalidades esperadas;

• Os custos dos projetos extrapolam mais de

180% dos valores previstos;

20

16

38




• Prazos excedem mais de 220%

• Empresas de nível 1 dedicam cerca de 55% dos

esforços para corrigir defeitos

• Esses índices vão sendo gradativamente reduzidos à

medida que elas adotam um modelo de qualidade

20

16

39



Defeitos, Erros e Falhas

• Defeito: deficiência mecânica ou algorítmica que, se ativada, pode levar a uma falha

• Erro: item de informação ou estado de execução inconsistente

• Falha: evento notável em que o sistema viola suas especificações

20

16

40



Defeitos no Software

• A maior parte é de origem humana

• São gerados na comunicação e na transformação de informações

• Continuam presentes nos diversos produtos de software produzidos e liberados

• A maioria encontra-se em partes do código raramente executadas

20

16

41



Defeitos no Software

• Quanto antes a presença do defeito for revelada, menor o custo de correção do defeito e maior a probabilidade de corrigi-lo corretamente

• Principal causa: tradução incorreta de informações

• Solução: introduzir atividades de VV&T ao longo de todo o ciclo de desenvolvimento

20

16

42



Finalidade dos Testes

• Verificar se todos os requisitos do sistema foram corretamente implementados

• Assegurar, na medida do possível, a qualidade e a corretude do software produzido

• Reduzir custos de manutenção corretiva e retrabalho

• Assegurar a satisfação do cliente com o produto desenvolvido

20

16

43



Finalidade dos Testes

• “Teste é o processo de demonstrar que erros não estão presentes”

• “O objetivo do teste é demonstrar que um programa executa suas funções corretamente”

• “Teste é o processo de criação de confiança de que o programa faz o que ele tem que fazer”

• Teste é o processo de executar um programa com a intenção de encontrar defeitos

20

16

44



Testes de Programas

• Podem revelar a presença de defeitos, NÃO a ausência.

• Principal técnica de validação para requisitos não-funcionais – O software é executado para ver como se

comporta.

• Devem ser usados em conjunto com a verificação estática para fornecer uma cobertura mais completa de V&V.

20

16

45



Tipos de teste

• Teste de validação – Pretende mostrar que o software atende as

necessidades dos usuários;

– Um teste bem sucedido é aquele que mostra que um requisito foi adequadamente implementado.

• Teste de defeitos – Testes projetados para descobrir defeitos de

sistema;

– Um teste de defeitos bem sucedido é aquele que revela a presença de falha em um sistema;

20

16

46



Teste e Depuração

• Testes de depuração e de defeitos são processos distintos

• Verificação e validação estão relacionados ao estabelecimento da existência de falhas em um programa

• Depuração está relacionado à localização e repararação dessas falhas

20

16

47



O Modelo V de Desenvolvimento

20

16

48



SWEBOK

• Guide to the Software Engineering Body of Knowledge

• Parceria entre a IEEE Computer Society e Association for Computing Machinery

• Promover a profissionalização da engenharia de software

• Criar um consenso sobre as áreas de conhecimento da engenharia de software e seu escopo

20

16

49



SWEBOK

• Objetivos

• Oferecer uma visão consistente da engenharia de software no âmbito mundial

• Deixar claros os limites de engenharia de software com respeito a outras disciplinas como ciência da computação, gerência de projetos, matemática e outras

• Caracterizar o conteúdo da disciplina de Engenharia de Software

• Prover um acesso tópico ao corpo do conhecimento da engenharia de software

• Prover uma base para desenvolvimento curricular e material de licença e certificação.

20

16

50


Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala 2016 51


Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala 2016 52



Software testing

• Teste é uma atividade realizada para avaliar a qualidade de produto e, para melhorá-la, através da identificação de defeitos e problemas.

• Esta área é dividida em cinco sub-áreas: • Fundamentos de teste de software

• Níveis de teste

• Técnicas de teste

• Medidas relacionadas ao teste

• Processo de teste

20

16

53



Software testing

20

16

54



Software testing

• Fundamentos do teste de software

• Usado para estudar as terminologias usadas nessa (KA).

• Termos na engenharia de software descrevem mal funcionamento, defeito, falha, falta, erro e muitas outras.

• Relacionamento entre teste e outras atividades.

20

16

55



Software testing

• Níveis de teste

• O alvo dos testes.

• Teste de software são normalmente realizados em diferentes níveis ao longo dos processos de desenvolvimento e manutenção.

• Objetivos do teste

• Testes são realizados tendo em vista um objetivo específico e têm diversos graus de precisão.

20

16

56



Software testing

• Técnicas de teste • Um dos objetivos dos testes é o de revelar o

máximo possível do potencial de fracasso e muitas técnicas têm sido desenvolvidas para fazer isso: tentativas de "quebrar" o programa.

• Testes ‘caixa preta’ e ‘caixa branca’.

• Baseados na intuição e experiência do engenheiro de software.

• Técnicas baseadas em especificação: • Tabelas de decisão

• Baseada em máquina de estado finitos

• Testes aleatórios

20

16

57



Software testing

• Medidas relacionadas ao teste

• A medição é geralmente considerada fundamental para a qualidade análise.

• A medição pode também ser utilizado para otimizar o planejamento e execução dos testes.

• Teste de gestão pode usar várias medidas para monitorar o progresso.

20

16

58



Software testing

• Processo de Teste • Considerações práticas

• Atitudes e programação em conjunto como um componente muito importante para o sucesso nos testes, visto que, atitudes colaborativas para testes e atividades de garantia de qualidade se mostram eficientes.

• Atividades de teste • Planejamento

• Geração de casos de teste

• Desenvolvimento do ambiente de testes

• Execução ...

20

16

59


Documents

Teste de Software - facom.ufu.brbacala/ES/16-Introducao aos Testes.pdf · •Teste de software. Relacionado ao exercício e à observação do comportamento do produto ... Teste e