Introdução ao Teste

de Software
disciplina em nível de Pós-graduação em
Engenharia de Software

Prof. Dr. José Eduardo Zindel Deboni

[email protected]

Objetivos e Ementa da Disciplina

Objetivo do Curso
Habilitar o aluno na elaboração e na execução de um plano de teste de software,
Discutir a importância da fase de teste na obtenção de produtos de software de
qualidade.

Ementa da Disciplina
Introdução: princípios, limitações, conceitos básicos e terminologia. Técnicas de
Projeto de Casos de Teste. Teste Funcional. Teste Estrutural. Teste de Caixa Preta.
Automação da Atividades de Testes. Testes de Software Orientado a Objetos. Testes
de Software para internet. Técnicas de Depuração de Software. Ferramentas de
Suporte ao teste de software. Exercícios práticos.

1
Apresentação da Disciplina

Teste de Software não é Garantia de Qualidade

Teste é uma ferramenta da GQ. Objetivos são ligeiramente diferentes.
O teste de software sabe que existem erros e tenta localizá-los
A Garantia da Qualidade tenta evitar que os erros aconteçam.

Curso de Pós-graduação em Engenharia de Software

- trata o software como uma disciplina de engenharia
- testes fazem parte da engenharia (ver exemplo no próprio IPT)

O objetivo principal capacitar o aluno na elaboração e execução de um plano de teste

de software .
- abordagem teórico - prática
- boas práticas de Engenharia
- rigor teórico exigido pela Academia
- voltado para problemas reais (profissionais)
- recursos disponíveis: Open Source, Eclipse, Java.

Estrutura do Curso

Aula 1 - Introdução à disciplina de Testes de Software

Aula 2 - Descrição do Processo de Teste de Software
Aula 3 - Tipos de teste, teste funcional. (caixa preta)
Aula 4 - Teste estrutural (caixa branca)
Aula 5 - Teste de unidade com JUnit.
Aula 6 – Teste de integração em sistemas orientados a objeto
Aula 7 – Cobertura de Testes, Testes em Banco de Dados e Mutantes
Aula 8 - Testes de Usabilidade e Testes em Aplicações web
Aula 9 - Testes de Desempenho e Testes de Carga com JMeter
Aula 10 - Estudo de Artigos, tópicos avançados
Aula 11 - Estudo de Artigos, tópicos avançados
Aula 12 - Revisão geral e planejamento de testes
Aula 13 - Avaliação final

2
Avaliação das Disciplina

▪A avaliação desta disciplina será composta por 3 atividades:

– Prova teórica e prática individual. (PR)
– Exercícios desenvolvidos durante o curso no laboratório e (EX)
– Estudos de Artigos (ex. Seminário) (SE)

▪A média final (MF) será dada por:

▪MF = 0,7*PR + 0,1*EX + 0,2*SE

▪Com base na MF o conceito final será

– 0,0 a 5,0 – conceito D
– 5,1 a 7,0 – conceito C
– 7,1 a 8,5 – conceito B
– 8,6 a 10,0 – conceito A

Motivação para estudar Teste de Software

1. Para fazer sistemas melhores

Estou envolvido no desenvolvimento de sistemas

Me interesso por melhorar os sistemas que desenvolvo.

Algumas perguntas:

O Estudo de Testes de Software pode me ajudar a desenvolver melhor os

sistemas ?

Os Testes de Software podem ajudar a melhorar os sistemas?

Como me organizar e elaborar um plano para aplicar os testes?

Como analisar os resultados e melhorar o processo?

3
Motivação para estudar Teste de Software
2. Uma importante alternativa profissional

Sou interessado em desenvolver sistemas profissionalmente.

Quero ganhar dinheiro com isso!

Como não perder dinheiro na manutenção de software?

Como oferecer um serviço especializado e diferenciado?

Como poder atuar em diversos projetos diferentes?

Como aumentar minha empregabilidade nesta área?

Motivação para estudar Teste de Software?

3. Como ferramenta de pesquisa em Eng. de Software

Sou pesquisador na área de Engenharia de Software

Minha pesquisa exige medidas de qualidade, produtividade,

confiabilidade, desempenho e outras

Minha pesquisa está ligada ao aumento da produtividade e à diminuição

do retrabalho. Pesquiso como reduzir erros em software.

Pesquiso novas técnicas de teste em software, como compará-la com as

já existentes?

Posso me utilizar de resultados de teste para quantificar minha pesquisa?

Estou desenvolvendo uma ferramenta de software, como testá-la?

4
Algumas Referências Bibliográficas

The Art of Software Testing,

Glenford Myers
(clássico)
Software Testing
by Ron Patton
☺

Testing Computer Software, 2nd ed.

Kaner, Cem
☺

Practical Guide to Testing Object-Oriented Software

by David A. Sykes, John D. McGregor


Just Enough Software Test Automation

Daniel J. Mosley, Bruce A. Posey


Referências Em Portugues

INTRODUCAO AO TESTE DE SOFTWARE

J C Maldonado; M Delamaro; M E Delamaro
ISBN: 8535226346
Bom livro com tópicos avançados. Obrigatório para quem quer
pesquisar na área (ver resenha no meu blog)

BASE DE CONHECIMENTO EM TESTE DE SOFTWARE A. Bastos,E Rios,R

Cristalli (Livro Texto para a Certificação da ALATS, só compre se for fazer
o exame, entendo que o curso é suficiente para passar neste exame )

TESTE DE SOFTWARE - 2 ED Emerson Rios Trayahu Moreira

Muito Ruim, fuja!

5
Nova boa referencia em português

Um software de qualidade não pode ser construindo sem a

utilização de técnicas de teste e análise de software. Este
livro apresenta um conjunto de técnicas de teste e análise
em uma prática moderna. Escrito em linguagem acessível,
abrange tópicos bem aprofundados e oferece uma visão
geral sobre o assunto.
▪ Editora: Artmed
▪ Autor: MICHAEL YOUNG & MAURO PEZZÈ
▪ ISBN: 9788577802623
▪ Origem: Nacional
▪ Ano: 2008
▪ Edição: 1
▪ Número de páginas: 512
▪ Acabamento: Brochura
▪ Formato: Médio

Referências para pesquisa:

▪Artigos Científicos:
▪Fonte Primária, Conselho Editorial, IEEE, ACM, Teses, Dissertações, Livros,
Anais de Congressos respeitados ( SBC). Quanto mais recentes melhores!
Precisam existir.

▪Artigos de Divulgação:
▪Fonte Secundária, Revistas técnicas da área, livros de divulgação, Congressos
de divulgação. Podem ser usados em parte.

▪White Papers:
?
▪Autores conhecidos, fontes seguras, recuperáveis, entidades confiáveis

▪Artigos Ruins:
▪Autores desconhecidos, fontes inseguras, opiniões pessoais, publicidade de
produtos, artigos suspeitos e tendenciosos. Livros ruins.

6
Um nome para cada coisa : Teste de Software
Termos e Definições I
▪ Software são todos os produtos do processo de desenvolvimento de um
programa de computador, que tem uma finalidade prática.

▪ Software não é só o programa executável, mas todo o produto gerado no

processo de desenvolvimento.

▪ Software inclui a especificação, a documentação, as mensagens, ícones,

testes a interface gráfica e também o código fonte e o executável.

Teste de Software (primeira definição)

Exame dos produtos de software para determinar a sua
qualidade, a natureza e o seu comportamento sob certas
condições.

Termos e Definições – II
Dando nomes à coisa
Padrão IEEE (1983)
IEEE Std 729-1983 Standard Glossary of Software Engineering Terminology.

failure (falha) ocorre quando o programa apresenta algum problema

fault (defeito) é o que existe no programa

error: (erro) é uma ação humana que resulta em um defeito.

Um defeito pode provocar uma falha no programa

Um defeito pode ser reparado com uma mudança no código
Não existe defeito se o programa não falhar.

7
 Termos e Definições – III
Dando nome à coisa
Verbete: falha
[Do lat. fallia.]
2. Falta, defeito.
3. Omissão, lacuna, falência.

Verbete: erro
(ê)[Dev. de errar.]
1. Ato ou efeito de errar.
2. Juízo falso; desacerto, engano.
3. Incorreção, inexatidão.
4. Desvio de bom caminho; desregramento, falta.

A língua é uma arma perigosa, você pode conseguir muito inimigos com ela.
Erro implica em juízo falso (Alguém errou), culpa, não ajuda a resolver o problema.
Falha não traduz a real gravidade é apenas uma omissão, uma lacuna.
Coloquialmente vamos usar BUG

Termos e Definição - IV

Programação código Uso / Operação

erro defeito falha

bug

8
Termos e Definições

▪Especificação do Produto
– É um documento que estabelece o que o software deve fazer.
– É parte do software e também deve ser testado
– Pode ser mais ou menos formal

– Vamos voltar ao assunto mais tarde ao analisar o processo de

desenvolvimento de software.

– Por definição:

Um software está correto se

ele atende à sua especificação

O que é um BUG?

1. Quando o software não faz algo que foi especificado (*)

2. Quando o software faz algo que a especificação diz que não faz,

3. Quando o software faz algo que não foi especificado, e não deveria

4. Quando o software não faz algo que não foi especificado, mas deveria,

5. O software é difícil de entender, usar, é lento ou, sob os olhos de quem

testa não está certo.

(*) Notar que a especificação pode ser explícita (dita) ou implícita (não dita)

9
 Erros de Software Famosos
Bug do Ponto Flutuante do Pentium, 1994
(4195835 / 3145727) * 3145727 – 4195835 = ?
A INTEL detectou o problema, mas não foi considerado crítico
Custo da reposição dos chips foi de US$400 milhões

Bug do Ano 2000,

Decorrente do uso de 87, 56 para representar 1987 ou 1956
Estima-se que mais de US$ 1 bilhão foi gasto na correção
muita gente ganhou dinheiro, mas passou o réveillon do ano 2000
trabalhando e com medo

Jogo Lion King da Disney

Primeira tentativa da Disney neste mercado
Não executou em diferentes computadores e
Gerou uma série de reclamações e insatisfação dos consumidores

Qual a origem dos bugs?

– Especificação 50%
– Projeto 25%
– Código 20%
– Outros 5% Ref. Patton, 2001

Os erros do código são eliminados, em geral, na compilação.

Um projeto ruim pode induzir a erros, mas
É a falta de entendimento do problema a grande causa de erros,

A VERDADEIRA ORIGEM DOS BUGS É ACHAR QUE ELES NÃO

ACONTECEM. O MAIOR ERRO DO DESENVOLVEDOR É ACHAR QUE ELE
NÃO ERRA.

PARA AUMENTAR A QUALIDADE DEVEMOS AUMENTAR A CONSCIÊNCIA

DE QUE O ERRO É POSÍVEL, SEMPRE.

10
questões para discussão...

1) Segundo a definição de um bug, o ano 2000 foi um bug ? Por

que?

2) Qual o problema em se testar um programa apenas da forma

como ele deve ser usado?

3) Errar é humano. O que isso tem que ver com software?

4) É possível se detectar todos os erros da fase de especificação?

Por que?

A busca por uma nova definição:

▪Teste de software é o processo para encontrar falhas no software

▪Um software falha quando ele não atende à sua especificação
▪A especificação traduz a vontade do usuário do software, assim
▪Um software falha onde e quando ele não atende a vontade do seu usuário

▪Teste de software é um processo da engenharia de software para encontrar

onde e quando ele não atende a vontade do seu usuário.

▪Como o objetivo da engenharia de software é produzir software melhor :

dentro da especificação, ou seja atendendo as vontades dos usuários:

▪Teste de software é um processo para melhorar o software, encontrando

onde e quando ele não atende a vontade do seu usuário.

11
Definição de Teste Software

Teste de software é a atividade

do desenvolvimento de software que tem
como objetivo encontrar bug, o mais cedo possível e
garantir que eles sejam corrigidos, aumentando a
qualidade do software.

Os analistas de teste não são os mais populares das equipes de projeto.

Ninguém gosta de ser o portador de más notícias (ninguém?)...
Cuidado com a linguagem para não gerar uma reação contrária
Relate também os progressos do desenvolvimento, o aumento da qualidade.

Encontramos bugs: defeitos e falhas mas não erros.

Escolhendo um nome para o profissional

Programador

Analista de Sistemas

Desenvolvedor
Engenheiro de Software

Testador? Tester
Analista de Teste,
Analista de Qualidade
Engenheiro de Teste de Software
Engenheiro de Software especializado em testes.

12
Perfil do analista de teste de software

• São exploradores, curiosos, tem uma postura questionadora.

• São resolvedores de problemas. Gostam de desafios.
• Devem ser incansáveis, pacientes
• Precisam ser criativos
• Devem ser perfeccionistas
• Precisam exercer um julgamento
• Precisam ser diplomatas (para serem aceitos)
• Precisam ser persuasivos.
•Analise o perfil acima com o perfil de um programador.
•O analista de testes tem um perfil semelhante ao de um programador.

Conhecendo o professor

José Eduardo Zindel Deboni

Engenheiro Naval, USP, 1983

Mestre em Engenharia Naval (Área de Controles e Automação), USP,1990
Doutor em Engenharia de Computação (Engenharia de Software), USP, 1996

Pesquisador no IPEN, Diretor de Informática da COPESP (Min. Marinha)

Professor de Graduação na UNIBAN (4 anos).
Consultor independente em modelagem (UML) e projetos de software.
Sócio da Voxxel Consultoria de Sistemas (www.voxxel.com.br)
Hoje R&D Manager na Hexagon (www.hexagon.com.br)
Email : [email protected]
Blog: www.eduardodeboni.com/blog
Website: www.eduardodeboni.com
Twitter : @deboni

13
Conhecendo os alunos

– Qual é o seu nome?

– Qual o seu envolvimento no desenvolvimento de software?

– Qual a sua área de interesse em pesquisa?

– O que você espera do curso?

Histórico dos Testes de Software em publicações ...

1924 – Walter Shewhart no Bell Labs escreveu ao chefe sugerindo o uso de estatisticas para melhorar a qualidade de
telefones (qualidade)

1976 – Michael Fagan publicou um paper sobre Design and Code Inspections

1979 – Glenford Myers publicou seu livro (clássico) “ A Arte do Teste de Software”

1987 – IEEE publica um padrão com uma terminologia para a área de Engenharia de Software.

1983 – Boris Beizer publicou Software Testing Techniques.

Usou termos Teste Funcional (Caixa preta) e Teste Estrutural (caixa branca).

1994 - Brian Marick The Craft of Software Testing Inclui elementos e Orientação a Objetos.

1995 - Edward Kit publica Software Testing in The Real World, bom livro mas com os mesmos princípios.

1995 – Produtos de automação do processo de teste começam a se popularizar.

1999 - Kaner, Cem publica Testing Computer Software, 2nd ed. Aborda um ponto de vista prático

2000 – Kent Beck e Erick Gamma publicam o artigo: Test Infected: Programmers Love Writing Tests”
onde apresentam o Junit. Ferramenta essencial para o desenvolvimento na filosofia do XP.

2003 – Kent Beck e outros Test Driven Development, o teste como método de desenvolvimento

14
 Controle do Desenvolvimento de Software

▪Qualidade
– Independe da Funcionalidade, consome recursos (prazo e custo
– deseja-se alta (cliente) e (desenvolvedor)
▪Prazo de execução
– Tempo para se obter o produto de software.
– Deseja-se baixo (cliente).
▪Custo (e Preço) do desenvolvimento
– Preço:
• Interessa ao cliente e ao desenvolvedor. Ligado a quanto o cliente irá pagar pelo
produto de software.
• Deseja-se baixo (cliente). Deseja-se alto (desenvolvedor)
– Custo do desenvolvimento
• Interessa ao desenvolvedor. Ligado aos gastos que se tem com o desenvolvimento.
• Deseja-se baixo (desenvolvedor)
▪Funcionalidade (Escopo)
– Corresponde às funções de um software.
– Deseja-se alta (cliente e desenvolvedor).

Teste de Software
(visão do teste no processo de desenvolvimento)
Meio para garantir a funcionalidade do software ?
Faz parte do processo de desenvolvimento (garante funcionalidade ? )

Aumenta a qualidade do produto

Não garante qualidade e
Não interfere em todos os aspectos da qualidade

Custo: Consome recursos (aumenta o custo total ? )

Prazo
Interfere pouco no prazo do desenvolvimento
O prazo é mais alterado por retrabalho da programação

Uma visão radical : Teste como Motor do Desenvolvimento (TDD)

15
Teste de Software como Especificação
Teste de Software garante a funcionalidade do sistema

Teste de Software define que o sistema precisa fazer (especificação)

Uma abordagem incentivada pelas metodologias Ágeis:

Test before code usa o teste como uma especificação.

Um grupo (especificador) diz o que quer dizendo como testar o código.

A FUNÇÃO DO CLIENTE É DEFINIR COMO O SISTEMA SERÁ TESTADO

SE O SISTEMA PASSAR NO TESTE ELE ESTÁ APROVADO

O TESTE É A ESPECIFICAÇÃO

Frase do dia

Se você não testou,

não sabe se está funcionando.

16
 Apresentar as definições e os fundamentos do teste
de software. Analisar alguns axiomas nesta área.

PARTE 2 - FUNDAMENTOS DO
TESTE DE SOFTWARE

O que é um Bug?

▪ Informalmente referenciado como:

▪ falha, “pobrema”, pau, anomalia, abend...

Código do
erro Programa falha
(defeito)

bug
A retirada de um bug de software é uma operação de debug (depuração)

17
O custo dos bugs?

Não existe dúvida que eliminar erros de um produto é caro,

Tradicionalmente se acredita na escala
Custo na especificação =1
Custo no projeto = 10
Custo na codificação = 100
Custo na entrega = 1000
•

Beck, 2000 afirma que o custo da mudança de software não muda muito com o
tempo. Essa é a fundamentação técnica da eXtreme Programming

O ideal é que o erros não apareçam (processo de desenvolvimento)

ou que sejam eliminados o mais cedo possível. Todos concordam com isso, mas
todos concordam também que os erros são inevitáveis, dai a importância dos
testes de software.

Axiomas(*) de Teste de Software

(*)axioma(cs ou ss)[Do gr. axioma, pelo lat. axioma.]

S. m.
1. Filos. Premissa imediatamente evidente que se admite como
universalmente verdadeira sem exigência de demonstração.
3. Lóg. Proposição que se admite como verdadeira porque dela se podem
deduzir as proposições de uma teoria ou de um sistema lógico ou matemático.

Ref. Aurélio, Dicionário Eletrônico, 1994.

Axiomas de Testes de Software são afirmações sobre teste que vamos admitir como
válidas.

18
Axiomas do Teste de Software (1)

É impossível testar um programa completamente

O número de entradas possíveis é muito grande

•O número de saídas possíveis é muito grande
•O número de caminhos (internos) é muito grande
•A especificação do software é subjetiva, dúbia ou incompleta
•A avaliação de alguns aspectos do software é subjetiva
•Os critérios de avaliação podem mudar com o tempo

•Ex.: Um simples entrada de um número inteiro pode receber um grande

número de possibilidades: número inteiros, números reais, caracteres,
símbolos como “.” “,” “backspace”... (ver o exemplo do Pentium)

Corolário do Axioma anterior

O Teste de Software é uma relação de custo/benefício

▪Se uma funcionalidade não é testada, ela pode conter um bug
▪Não é viável se testar todas as funcionalidades
▪Assim, deve-se decidir o que e quanto testar, e o que não testar

número Custo dos testes

Ponto de Ótimo
de bugs
de testes

Custo da
Não correção dos
bugs existentes (Difícil de medir)

qtd de testes / tempo

19
Axiomas de Teste de Software (3)

Os testes não podem mostrar que os bugs não existem

Como um exterminador de pragas, você não pode examinar uma casa e afirmar
definitivamente que ela não possui nenhum tipo de praga.

Um médico não pode afirmar com exatidão que uma pessoa não tem nenhuma
doença

Um analista de teste de software pode, no máximo, afirmar que não existem indícios
de bugs no software.

Se continuar a testar, ou aumentar o critério de procura, pode encontrar outros bugs.

Por isso que os testes não provam nunca que um programa não tem erros.

Axiomas de Teste de Software (4)

Quanto mais bugs você acha, mais erros existem

Os bugs tem origem em um entendimento equivocado do problema
Este entendimento gera uma “família” de erros
Um erro acaba justificando ou gerando outro.
Assim como com insetos, se você vê uma barata na cozinha com certeza existem
outras, muitas outras, por perto.

Paradoxo do Pesticida:

Os bugs se tornam resistentes aos testes.

Os mesmos testes aplicados repetidas vezes podem não detectar falhas que ainda
permanecem no programa.

20
Axiomas de Teste de Software (5)

Não será possível corrigir todos os bugs encontrados

Diversas razões para não se corrigir os bugs (ou alguns bugs):

- Falta de tempo ou de recursos

- Pouca importância do bug, existem soluções alternativas (reset no
computador)
- A correção é muito arriscada. Melhor evitar que as condições de erro
aconteçam
- Simplesmente não vale a pena ou não é um bug de verdade.

Axiomas de Teste de Software (6)

É difícil dizer que um bug é um bug mesmo

– A Especificação pode estar errada mesmo

– O sistema deve se comportar assim mesmo.
– A percepção do analista de teste está errada,
– O sistema é difícil de entender e pode estar certo.

Ex. Erros de tradução/ interpretação

Em um relatório os dados apareciam incorretos, e se relatou a falha como um defeito

no software. Uma investigação mais aprofundada mostrou que estava-se
interpretando os campos de forma errada e o software estava correto. O erro estava
no relatório e no seu uso.

– Last updade user : último usuário que atualizou o documento

– Last user update : última data de atualização do documento pelo usuário
– Last user : data do último uso do documento
– Last username : nome do último usuário do documento
– Last update : data da última atualização do documento

21
Axiomas de Teste de Software (7)

A especificação do software nunca está completa

Deve-se assumir que as especificações vão mudar com o tempo

O ambiente é alterado enquanto o software evolui
Os testes podem mesmo orientar o desenvolvimento (XP)

Axiomas de Teste de Software (8)

Os analistas de teste não são muito populares

▪ Ninguém gosta de ser o portador de más notícias

▪ O analista deve contribuir para
▪ Um relato imparcial e profissional do bug é a melhor política
▪ Um relato positivo é sempre bem vindo, comemore um baixo número de bugs

▪ Ex.1 O programa está muito ruim. Não executa nada do que foi especificado. Já no
início do uso do sistema , teclando Arquivo> Abrir... o programa apresenta uma
mensagem de erro.

▪ Ex.2. Bug encontrado na operação Arquivo>Abrir...O programa exibe a mensagem:

Nenhum arquivo foi localizada. O programa deveria exibir uma janela de diálogo
para seleção de um arquivo.

22
Axiomas de Teste de Software (9)

Teste de Software é uma atividade técnica e exige

disciplina

▪ A atividade de teste de software é

– - uma atividade técnica
– - exige bons conhecimentos de programação
– - Organização é essencial
– - facilidade de expressão escrita
– - exige diplomacia e profissionalismo
– - exige experiência

Resumo

• O objetivo dos testes de software é encontrar bugs!

– Encontrar o mais cedo possível e

– Garantir que eles sejam corrigidos.
– Contribuir para o desenvolvimento do sistema com qualidade

• Lembrando que:

1. Não é possível se testar um programa completamente

2. O teste de software é uma atividade de risco
3. Não se pode provar que os bugs não existem
4. Quanto mais bugs encontrar, mais bug existirão
5. Nem todos os bugs serão corrigidos
6. É difícil dizer que um bug é um bug.
7. A especificação nunca estará completa
8. Os analistas de teste não são muito populares
9. Teste de software é uma atividade técnica que exige disciplina

23