Upload
phungdiep
View
226
Download
0
Embed Size (px)
Citation preview
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
Teste de Software: introdução
Prof. Sílvio Bacalá Jr – 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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
V & V estática e dinâmica
20
16
6
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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.
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
Limitações de Prova de Teorema
• Requer conhecimento de um expert
• Processo manual
• tedioso e passível de erro
20
16
9
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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.
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
Exemplo
public class Customer {
String getName() {…}
}
public class Bank{
static Bank createBank() {…}
Customer createCustomer(String name) {…}
}
20
16
14
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
Exemplo
public class Customer {
String getName() {…}
}
public class Bank{
static Bank createBank() {…}
Customer createCustomer(String name) {…}
}
Bank bank = Bank.createBank();
String name = “customer1“;
Customer cust = bank.createCustomer(name);
Assert.assertEquals(name, cust.getName());
20
16
15
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
Exemplo
public class Customer {
String getName() {…}
}
public class Bank{
static Bank createBank() {…}
Customer createCustomer(String name) {…}
}
Bank bank = Bank.createBank();
String name = “customer1“;
Customer cust = bank.createCustomer(name);
Assert.assertEquals(name, cust.getName());
Entrada e resultado esperado:
20
16
16
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
Exemplo
public class Customer {
String getName() {…}
}
public class Bank{
static Bank createBank() {…}
Customer createCustomer(String name) {…}
Customer search(String name) {…}
}
Bank bank = Bank.createBank();
String name = “customer1“;
Customer cust = bank.search(name);
if (cust == null) {
Customer cust = bank.createCustomer(name);
Assert.assertEquals(name, cust.getName());
}
Condições de execução:
20
16
17
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
Teste de sort
public class SortTest{
public static void main(String[] args) {
sort(new int[]{});
}
}
20
16
23
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
Motivação para Teste
20
16
35
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
20
16
36
Motivação para Teste
As falhas causam
prejuízos
financeiros
As falhas causam a
perda de confiança
do cliente
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
Motivação para Teste
• 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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
Motivação para Teste
• 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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
O Modelo V de Desenvolvimento
20
16
48
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
Software testing
20
16
54
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala
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