Aula 01

Aula 01 Teste de Software
Introduo ao Teste de Software
Mestrado em Engenharia de Computao

Instituto de Pesquisas Tecnolgicas de So Paulo
por
Prof. Dr. Jos Eduardo Zindel Deboni
Objetivos e Ementa da Disciplina

Objetivo do Curso
Avaliar a importncia da disciplina de teste de software na obteno
de produtos de qualidade.
Habilitar o aluno na elaborao e execuo de um plano de teste de

em um processo de desenvolvimento de software
Ementa da Disciplina
Introduo: princpios, limitaes, conceitos bsicos e terminologia.
Tcnicas de Projeto de Casos de Teste. Teste Funcional. Teste Estrutural.
Teste de Caixa Preta. Automao da Atividades de Testes. Testes de
Software Orientado a Objetos. Testes de Software para internet.
Tcnicas de Depurao de Software. Ferramentas de Suporte ao teste de
software. Exerccios prticos.
Prof. J.E.Deboni 1
Apresentao da Disciplina
Teste de Software no Garantia de Qualidade:
O Teste verifica a existncia de erros em algo que j est pronto,
A Garantia da Qualidade tenta evitar que os erros aconteam.
Curso de Ps-graduao em Engenharia de Software

- ps-graduao pressupe que todos sejam graduados em software
- trata o software como uma disciplina de engenharia
- testes fazem parte da engenharia (ver exemplo no prprio IPT)
O objetivo principal:
Capacitar o aluno na elaborao e execuo de um plano de teste de software
- abordagem terico - prtica
- Boas prticas de Engenharia
- Rigor terico exigido pela Academia
- Focando problemas reais (profissionais)
- recursos disponveis: Opensource, Apache, Java.
Conhecendo o professor
Jos Eduardo Zindel Deboni
Engenheiro Naval, USP, 1983

Mestre em Engenharia Naval (rea de Controles e Automao), USP,1990
Doutor em Engenharia de Computao (Engenharia de Software), USP, 1996
Pesquisador no IPEN, Diretor de Informtica da COPESP (Min. Marinha)
Professor de Graduao na UNIBAN (4 anos)
Consultor independente em modelagem (UML) e projetos de software
Scio da Voxxel Consultoria de Sistemas (www.voxxel.com.br)
Hoje coordena equipe de desenvolvimento da Sisgraph (www.sisgraph.com.br)
Email : deboni@voxxel.com.br
Website: www.voxxel.com.br/deboni (em manuteno)
Lates : http://buscatextual.cnpq.br/buscatextual/visualizacv.jsp?id=K4796864E7
Prof. J.E.Deboni 2
Conhecendo o Aluno
Qual o seu nome?
Qual o seu envolvimento no desenvolvimento de

software?
Qual a sua rea de interesse em pesquisa?

Voc acha que existe aplicao para testes de
software?
O que voc espera do curso?
Estrutura do Curso
Aula 1 - Introduo disciplina de Testes de Software
Aula 2 - Descrio do Processo de Teste de Software
Aula 3 - Tipos de teste, teste funcional.
Aula 4 - Teste estrutural esttico.
Aula 5 - Teste de unidade com JUnit.
Aula 6 - Tcnicas especiais para orientados a objeto
Aula 7 - Teste de cobertura / Testes em Banco de Dados
Aula 8 - Testes de Usabilidade / Testes em Aplicaes web
Aula 9 - Testes de Desempenho / Testes de Carga com JMeter
Aula 10 - Seminrio 1
Aula 11 - Seminrio 2
Aula 12 Seminrio 3 / Reviso geral
Aula 13 - Avaliao final
Prof. J.E.Deboni 3
Calendrio
Avaliao das Disciplina

A avaliao desta disciplina ser composta por 3 atividades:
Prova terica e prtica individual. (PR)
Exerccios desenvolvidos durante o curso no laboratrio (EX)
Seminrio sobre teste de software baseado em artigos. (SE)
A mdia final (MF) ser dada por:
MF = 0,5*PR + 0,2*EX + 0,3*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
Prof. J.E.Deboni 4
Porque estudar Teste de Software?

1. Para fazer sistemas melhores
1 . Estou envolvido no desenvolvimento de sistemas
2. Me interesso por melhorar os sistemas que desenvolvo.
Algumas perguntas:
Como o estudo dos 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?

2. Como uma alternativa profissional
1. Sou interessado em desenvolver sistemas

profissionalmente.
2. Quero ganhar dinheiro com isso!
3. Como no perder dinheiro na manuteno de software?
4. Como oferecer um servio especializado e diferenciado?
5. Como poder atuar em diversos projetos diferentes?
6. Como aumentar minha empregabilidade nesta rea?
Prof. J.E.Deboni 5

3. Como ferramenta de pesquisa em Engenharia de
Software
1. Sou pesquisador na rea de Engenharia de Software
2. Minha pesquisa exige medidas de qualidade, produtividade,

confiabilidade, desempenho e outras
3. Minha pesquisa est ligada ao aumento da produtividade e

diminuio do retrabalho. Pesquiso como reduzir erros em
software.
4. Pesquiso novas tcnicas de teste em software, como compar-la

com as j existentes?
5. Posso me utilizar de resultados de teste para quantificar minha

pesquisa?
6. Estou desenvolvendo uma ferramenta de software, como test-la?
Referncias Bibliogrficas usadas

The Art of Software Testing,
Glenford Myers
(clssico)
Software Testing
by Ron Patton
2nd Edio

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

Prof. J.E.Deboni 6
Referncias nacionais
Delmaro, Mrcio Eduardo; Maldonado, Jos Carlos;

Jino, Mario. Introduo ao teste de software. Rio
de Janeiro: Elsier, 2007.
O livro uma importante aquisio para os

verdadeiramente interessados em teste de software
e um dever estudar os temas de maior interesse.
Todas as pesquisas desta rea encontram agora um
ponto slido de partida. No possvel deixar de
citar a vasta bibliografia de 459 referncias, uma
excelente fonte de informao para quem
pretende realizar qualquer tipo de pesquisa na
rea.
Fiz uma resenha que est com o material da aula.
Referncias da Certificao ALATS
ALATS Associao Latino Americana de Teste

de Software (iniciativa local...)
Base de Conhecimento em Teste Software. 2 Ed. Rev.
ANDERSON BASTOS; RICARDO CRISTALLI ; TRAYAHU
MOREIRA ; EMERSON RIOS; 2007.
Melhor que a 1 edio. Aceitvel. Mas no a Base de
Conhecimentos de Teste de Software
Outros Livros em Portugus (No recomendados)
Prof. J.E.Deboni 7
Referncias para pesquisa:

Artigos Cientficos:
Fonte Primria, Conselho Editorial, IEEE, ACM, Teses, Dissertaes, Livros, Anais de
Congressos respeitados ( SBC). Quanto mais recentes melhores! Precisam existir.
Artigos de Divulgao:
Fonte Secundria, Revistas tcnicas da rea, livros de divulgao, Congressos de
divulgao. Podem ser usados em parte.
? White Papers:
Autores conhecidos, fontes seguras, recuperveis, entidades confiveis
Artigos Ruins:
Autores desconhecidos, fontes inseguras, opinies pessoais, publicidade de produtos,
artigos suspeitos e tendenciosos. Livros ruins.
Termos e Definies I
Software so todos os produtos do processo de desenvolvimento de um programa
de computador, que tem uma finalidade prtica.
Software no s o programa executvel, mas todo o produto gerado no processo
de desenvolvimento.
Software inclui a especificao, a documentao, as mensagens, cones, testes a
interface grfica e tambm o cdigo fonte e o executvel.
Do Aurlio: Verbete: teste
S. m.
1. Exame, verificao ou prova para determinar a qualidade, a natureza ou o
comportamento de alguma coisa, ou de um sistema sob certas condies.
2. Mtodo, processo, procedimento ou meios utilizados para tal exame,
verificao ou prova.
Teste de Software (primeira definio)

Exame dos produtos de software para determinar a
sua qualidade, a natureza e o seu comportamento
sob certas condies.
Prof. J.E.Deboni 8
Termos e Definies II
Dando nomes aos bois
Padro 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
Um defeito pode provocar uma falha no programa

Um defeito pode ser reparado com uma mudana no cdigo
No existe defeito se o programa no falhar.
error: (erro) uma ao humana que resulta em um defeito.
Termos e Definies III

Dando nome aos bois
Verbete: falha
[Do lat. fallia.]
2. Falta, defeito.
3. Omisso, lacuna, falncia.
Verbete: erro
()[Dev. de errar.]
1. Ato ou efeito de errar.
2. Juzo falso; desacerto, engano.
3. Incorreo, inexatido.
4. Desvio de bom caminho; desregramento, falta.
A lngua uma arma perigosa, voc pode conseguir muito inimigos com ela.
Erro implica em juzo falso (Algum errou), culpa, no ajuda a resolver o problema.
Falha no traduz a real gravidade apenas uma omisso, uma lacuna.
Nem falha nem erro: vou usar BUG
Prof. J.E.Deboni 9
Termos e Definio - IV
Programao cdigo Uso / Operao
erro defeito falha
bug
Termos e Definies
Especificao do Produto
um documento que estabelece o que o software deve fazer.
parte do software e tambm deve ser testado
Pode ser mais ou menos formal
Vamos voltar ao assunto mais tarde ao analisar o processo de

desenvolvimento de software.
Por definio:
Um software est correto se

ele atende sua especificao.
Prof. J.E.Deboni 10
O que um BUG?
1. Quando o software no faz algo que foi especificado,
2. Quando o software faz algo que a especificao diz que ele no faz,
3. Quando o software faz algo que no foi especificado, e no deveria

fazer
4. Quando o software no faz algo que no foi especificado, mas deveria

fazer,
5. O software difcil de entender, usar, lento ou, sob os olhos de quem

testa no est certo.
Notar que a especificao pode ser explcita (dita) ou implcita (no dita)
Famosos Erros de Software famosos

Bug do Ponto Flutuante do Pentium, 1994
(4195835 / 3145727) * 3145727 4195835 = ?
A INTEL detectou o problema, mas no foi considerado crtico
Custo da reposio dos chips foi de US$400 milhes
Bug do Ano 2000,

Decorrente do uso de 87, 56 para representar 1987 ou 1956
Estima-se que mais de US$ 1 bilho foi gasto na correo
muita gente ganhou dinheiro, mas passou o reveillon do ano 2000
trabalhando e com medo
Jogo Lion King da Disney

Primeira tentativa da Disney neste mercado
No executou em diferentes computadores e
Gerou uma srie de reclamaes e insatisfao dos consumidores
Prof. J.E.Deboni 11
Qual a origem dos bugs?
Especificao 50%
Projeto 25%
Cdigo 20%
Outros 5% Ref. Patton, 2001
Os erros do cdigo so eliminados, em geral, na compilao.

Um projeto ruim pode induzir a erros, mas
a falta de entendimento do problema a grande causa de erros,
Esta a verdadeira grande origem dos bugs.
Questes para discusso...

1) Segundo a definio de um bug, o ano 2000 foi um bug ?
2) Qual o problema em se testar um programa apenas da forma como ele
deve ser usado?
3) Voc concorda que a especificao a origem da maior parte dos
bugs?
4) possvel se detectar todos os erros na fase de especificao?
5) Sempre haver erros no cdigo? Qual a tendncia dos erros com o
tempo e as manutenes freqentes?
Prof. J.E.Deboni 12
Um nova definio:
Teste de software o processo para encontrar falhas no software
Um software falha quando ele no atende sua especificao
A especificao traduz a vontade do usurio do software, assim
Um software falha onde e quando ele no atende a vontade do seu
usurio
Teste de software um processo da engenharia de software para
encontrar onde e quando ele no atende a vontade do seu usurio.
Como o objetivo da engenharia de software produzir software melhor :
dentro da especificao, ou seja atendendo as vontades dos usurios:
. Teste de software um processo para

melhorar o software, encontrando onde
e quando ele no atende a vontade do
seu usurio
Objetivo do Teste de Software
Encontrar bugs!
Encontrar o mais cedo possvel e
garantir que eles sejam corrigidos
Os analistas de teste de software (Software testers) no so os membros

mais populares das equipes de projeto.
Ningum gosta de ser o portador de ms notcias (ningum?)...
Cuidado com a linguagem para no gerar uma reao contrria da

equipe de projeto
Relate tambm os progressos do desenvolvimento, o aumento da

qualidade.
Prof. J.E.Deboni 13
Termos e Definies V
Escolhendo um nome para o profissional
Programador
Analista de Sistemas
Desenvolvedor
Engenheiro de Software
Testador? Tester
Analista de Teste,
Engenheiro de Teste de Software

Engenheiro de Software especializado em testes.
Perfil do analista de teste de software

So exploradores, curiosos, tem uma postura questionadora.
So resolvedores de problemas. Gostam de desafios.
Devem ser incansveis
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.
Prof. J.E.Deboni 14
Histrico dos Testes de Software por meio dos livros...

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 (clssico) A Arte do Teste de Software
1987 IEEE publica um padro 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 Orientao a Objetos.
1995 - Edward Kit publica Software Testing in The Real World, bom livro mas com os mesmos princpios.
1995 Produtos de automao do processo de teste comeam a se popularizar.
1999 - Kaner, Cem publica Testing Computer Software, 2nd ed. Aborda um ponto de vista prtico
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 mtodo de desenvolvimento
Termos e Definies VI
Alguns termos usados tem uma definio especial.
Preciso [precision]
que fornece resultados com muitas casas decimais, com grandeza de detalhes
Acuracidade [accuracy]
que fornece resultados certos. Com os detalhes corretos.
Verificao [verification]
o processo de confirmao de algo.
Garante que estamos desenvolvendo o sistema corretamente.
Validao [validation]
o processo de confirmar que algo est de acordo com o esperado.
Garante que estamos desenvolvendo o sistema correto.
Reviso [revision]
uma verificao, implica que foi visto uma vez e ser revisto.
Inspeo [inspection]
uma verificao/reviso mais detalhada, feita com uma autoridade (inspetor)
Prof. J.E.Deboni 15
Termos e Definies V
Definindo alguns termos de qualidade
Garantia da Qualidade [ Quality Assurance]
Garante que o processo vai ter Qualidade, normalmente tomando providncias anteriores ao
processo acontecer. Capacitao, seleo de mtodos e procedimentos.
Controle de Qualidade [ Quality Control]

Controla (mede) a qualidade de um produto. Precisa que o produto esteja pronto. Pode medir uma
qualidade ruim. Pode ser do tipo passa - no passa. No muda, necessariamente, a qualidade
Teste
O teste uma ferramenta que pode ser usada pela Garantia da Qualidade, pelo Controle de
Qualidade e pelo desenvolvimento.
Qualidade
O que o cliente quer. O que o cliente valoriza. (Viso da qualidade total).
Qualidade[quality]
Um grau de excelncia, um conjunto de propriedades valorizadas pelo cliente.
Medidas da Qualidade I
Eficincia [efficiency]
Em engenharia realizar uma tarefa com uso otimizado de recursos. Um
motor mais eficiente que outro se consome menos combustvel.
Eficcia [efficacy]
Realizar algo com sucesso. A soluo eficaz se realmente consegue
resolver o problema. No est ligada eficincia da soluo.
Confiabilidade [ reliability]
Propriedade de quem se pode confiar. Que d resultados estveis, que se
pode depender. Mas no necessariamente com qualidade.
Prof. J.E.Deboni 16
Desempenho [performance]
Propriedade ligada ao tempo para se obter um resultado. Quanto maior o
desempenho, mais rpido se obtm o resultado.
Usabilidade [usability]
Propriedade de algo que pode ser usado com facilidade.
Portabilidade [portability]
Que pode ser transportado para outro lugar. Um software que pode ser executado
em outras mquinas. Que pode se portado para outras mquinas.
Completitude [completeness]
Propriedade de quem est completo. Qualidade de quem no necessita de
alteraes.
Corretitude [ correcteness]
Propriedade de quem est certo. Que oferece resultados esperados.
Escalabilidade [scalability]
Propriedade do sistema em mudar a escala de usurios, atendendo a um nmero
maior de usurios.
Ambiquidade [ambiquity]
O contrrio da clareza. Pode criar confuso interpretao.
Clareza [clarity]
O que est claro e no cria confuso na sua interpretao.
Consistncia [consistency]
Que oferece resultados coerentes com os dados fornecidos.
Manutenabilidade, Manutenncia [maintenance]

Propriedade de quem pode ser mantido, que recebe manuteno com facilidade.
Um aspecto de qualidade.
Testabilidade [testability]
Propriedade de quem testvel. Propriedade de quem pode ser testado.
Prof. J.E.Deboni 17
Controle do Desenvolvimento de Software
Qualidade
Independe da Funcionalidade, consome recursos (prazo e custo
deseja-se alta (cliente) e (desenvolvedor)
Prazo de execuo
Tempo para se obter o produto de software.
Deseja-se baixo (cliente).
Funcionalidade (Escopo)
Corresponde s funes de um software.
Deseja-se alta (cliente e desenvolvedor).
Custo (e Preo) do desenvolvimento
Preo:
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)
Teste de Software
Meio para garantir a funcionalidade do software

Faz parte do processo de desenvolvimento (garante funcionalidade)
Aumenta a qualidade do produto
No garante qualidade e
No interfere em todos os aspectos da qualidade
Custo
Consome recursos (aumenta o custo)
Prazo
Interfere pouco no prazo do desenvolvimento
O prazo mais alterado por re-trabalho da programao
Uma viso radical : Teste como Motor do Desenvolvimento
Prof. J.E.Deboni 18
Teste de Software como Especificao

Teste de Software garante a funcionalidade do sistema
Teste de Software define que o sistema precisa fazer (especificao)
Uma abordagem incentivada pelas metodologias geis:
Test before code usa o teste como uma especificao.
Um grupo (especificador) diz o que quer dizendo como testar o
cdigo.
A FUNO DO CLIENTE DEFINIR

COMO O SISTEMA SERA TESTADO, SE
O SISTEMA PASSAR NO TESTE ELE
ESTA APROVADO
TDD Test Driven Design

O teste levado ao extremo
O Teste como uma metodologia de desenvolvimento:
O processo de desenvolvimento invertido

No se desenvolve o cdigo e depois o teste,
Primeiro se desenvolve o teste e s ento o cdigo
De pequenos passos vai se acrescentando funcionalidades
que so testadas.
Se o teste falha, a funcionalidade corrigida
Se o teste passo, acrescenta-se mais funcionalidade
Se adapta bem XP (pair programming)
Prof. J.E.Deboni 19
Frase do dia
Se voc no testou,
no pode saber se est funcionando.
Parte II - Fundamentos do Teste de Software
Apresentar as definies e os
fundamentos do teste de software.
Analisar alguns axiomas nesta rea.
Prof. J.E.Deboni 20
O que um Bug?
Informalmente referenciado como:
falha, pobrema, pau, anomalia, abend...

Cdigo do
erro Programa falha
(defeito)
bug
A retirada de um bug de software uma operao de debug (depurao)
O custo dos bugs?
No existe dvida que eliminar erros de um produto caro,

Tradicionalmente se acredita na escala:
Custo na especificao = 1
Custo no projeto = 10
Custo na codificao = 100
Custo na entrega = 1000
Beck, 2000 afirma que o custo da mudana de software no muda muito

com o tempo. Essa a fundamentao tcnica da eXtreme Programming
O ideal que o erros no apaream (no processo de desenvolvimento)
Ou que sejam eliminados o mais cedo possvel. Todos concordam com
isso, mas todos concordam tambm que os erros so inevitveis, dai a
importncia dos testes de software.
Prof. J.E.Deboni 21
"The two most important tools an architect has are

the eraser in the drawing room and the sledgehammer
on the construction site./ As duas ferramentas mais
importantes para um arquiteto so a borracha na sala
de desenho e a marreta na obra
-- Frank Lloyd Wright
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 exigncia de demonstrao.
3. Lg. Proposio que se admite como verdadeira porque dela se podem deduzir
as proposies de uma teoria ou de um sistema lgico ou matemtico.
Ref. Aurlio, Dicionrio Eletrnico, 1994.
Axiomas de Testes de Software so afirmaes

sobre teste que vamos admitir como vlidas.
Obs.: Estes axiomas no so aceitos, academicamente, como tal.
Prof. J.E.Deboni 22
Axiomas do Teste de Software (1)
impossvel testar um programa completamente
O nmero de entradas possveis muito grande

O nmero de sadas possveis muito grande
O nmero de caminhos (internos) muito grande
A especificao do software subjetiva, dbia ou incompleta
A avaliao de alguns aspectos do software subjetiva
Os critrios de avaliao podem mudar com o tempo
Ex.: Um simples entrada de um nmero inteiro pode receber um grande

nmero de possibilidades: nmero inteiros, nmeros reais, caracteres,
smbolos como . , backspace... (ver o exemplo do Pentium)
Corolrio do Axioma anterior

O Teste de Software uma relao de custo/benefcio
Se uma funcionalidade no testada, ela pode conter um bug
No vivel se testar todas as funcionalidades
Assim, deve-se decidir o que e quanto testar, e o que no testar
nmero Custo dos testes

Ponto de timo
de bugs
de testes
Testes
Testes Superdimensioados
subdimensionados
(nmero) Custo dos

bugs existentes
qtd de testes
Prof. J.E.Deboni 23
Axiomas de Teste de Software (3)

Os testes no podem mostrar que os bugs no existem
Como um exterminador de pragas, voc no pode examinar uma casa e

afirmar definitivamente que ela no possui nenhum tipo de praga.
Um mdico no pode afirmar com exatido que uma pessoa no tem
nenhuma doena
Um analista de teste de software pode, no mximo, afirmar que no
existem indcios de bugs no software.
Se continuar a testar, ou aumentar o critrio de procura, pode
encontrar outros bugs.
Por isso que os testes no provam nunca que um programa no tem
erros.

Quanto mais bugs voc acha, mais erros existem
Os bugs tem origem em um entendimento equivocado do problema

Este entendimento gera uma famlia 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 no detectar falhas
que ainda permanecem no programa.
Prof. J.E.Deboni 24
BARATAS
Baratas habitam o planeta h mais de 300 milhes de
anos e tm a maior capacidade de adaptao do
reino animal. H quatro mil espcies no mundo.
Elas transmitem 38 tipos de doenas aos seres
humanos.
A francesinha vive em mdia 9 meses, pe ovos em

mdia 5 vezes ao longo de sua vida e coloca de 30 a
50 ovos por vez. A barata de esgoto vive de 2 3
anos, pe ovos de 10 20 vezes e coloca de 12 a 20
ovos em cada ooteca.

No ser possvel corrigir todos os bugs encontrados
Diversas razes para no se corrigir os bugs (ou alguns bugs):
- Falta de tempo ou de recursos
- Pouca importncia do bug, existem solues alternativas (reset no

computador)
- A correo muito arriscada. Melhor evitar que as condies de

erro aconteam
- Simplesmente no vale a pena ou no um bug de verdade.
Prof. J.E.Deboni 25

difcil dizer que um bug um bug mesmo
A Especificao pode estar errada mesmo
O sistema deve se comportar assim mesmo.
A percepo do analista de teste est errada,
O sistema difcil de entender e pode estar certo.
Ex. Erros de traduo/ interpretao
Em um relatrio os dados apareciam incorretos, e se relatou a falha como um defeito

no software. Uma investigao mais aprofundada mostrou que estava-se
interpretando os campos de forma errada e o software estava correto. O erro estava
no relatrio e no seu uso.
Last updade user : ltimo usurio que atualizou o documento
Last user update : ltima data de atualizao do documento pelo usurio
Last user : data do ltimo uso do documento
Last username : nome do ltimo usurio do documento
Last update : data da ltima atualizao do documento

A especificao do software nunca est completa
Deve-se assumir que as especificaes vo mudar com

o tempo
O ambiente alterado enquanto o software evolui
Os testes podem mesmo orientar o desenvolvimento
(XP)
Prof. J.E.Deboni 26

Os analistas de teste no so muito populares
Ningum gosta de ser o portador de ms notcias

O analista deve contribuir para
Um relato imparcial e profissional do bug a melhor poltica
Um relato positivo sempre bem vindo, comemore um baixo nmero de
bugs
Ex.1 O programa est muito ruim. No executa nada do que foi

especificado. J no incio do uso do sistema , teclando Arquivo> Abrir... o
programa apresenta uma mensagem de erro.
Ex.2. Bug encontrado na operao Arquivo>Abrir...O programa exibe a

mensagem: Nenhum arquivo foi localizada. O programa deveria exibir
uma janela de dilogo para seleo de um arquivo.

Teste de Software uma atividade tcnica e exige disciplina
A atividade de teste de software

- uma atividade tcnica
- exige bons conhecimentos de programao
- Organizao essencial
- facilidade de expresso escrita
- exige diplomacia e profissionalismo
- exige experincia
mas tambm pode ser divertida.
Prof. J.E.Deboni 27
Resumo
O objetivo dos testes de software encontrar bugs!
Encontrar o mais cedo possvel e

Garantir que eles sejam corrigidos.
Contribuir para o desenvolvimento do sistema com qualidade
Lembrando que:
1. No possvel se testar um programa completamente
2. O teste de software uma atividade de risco
3. No se pode provar que os bugs no existem
4. Quanto mais bugs encontrar, mais bug existiro
5. Nem todos os bugs sero corrigidos
6. difcil dizer que um bug um bug.
7. A especificao nunca estar completa
8. Os analistas de teste no so muito populares
9. Teste de software uma atividade tcnica que exige disciplina
Prof. J.E.Deboni 28

Aula 01

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Aula 01

Uploaded by

Copyright:

Available Formats

Aula 01 Teste de Software

Introduo ao Teste de Software

Mestrado em Engenharia de Computao

Objetivos e Ementa da Disciplina

Habilitar o aluno na elaborao e execuo de um plano de teste de

Curso de Ps-graduao em Engenharia de Software

Engenheiro Naval, USP, 1983

Qual o seu nome?

Qual o seu envolvimento no desenvolvimento de

Qual a sua rea de interesse em pesquisa?

O que voc espera do curso?

Avaliao das Disciplina

A mdia final (MF) ser dada por:

MF = 0,5*PR + 0,2*EX + 0,3*SE

Com base na MF o conceito final ser

Porque estudar Teste de Software?

2. Me interesso por melhorar os sistemas que desenvolvo.

Como o estudo dos Testes de Software pode me ajudar a desenvolver

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?

Porque estudar Teste de Software?

1. Sou interessado em desenvolver sistemas

2. Quero ganhar dinheiro com isso!

3. Como no perder dinheiro na manuteno de software?

4. Como oferecer um servio especializado e diferenciado?

5. Como poder atuar em diversos projetos diferentes?

6. Como aumentar minha empregabilidade nesta rea?

Porque estudar Teste de Software?

1. Sou pesquisador na rea de Engenharia de Software

2. Minha pesquisa exige medidas de qualidade, produtividade,

3. Minha pesquisa est ligada ao aumento da produtividade e

4. Pesquiso novas tcnicas de teste em software, como compar-la

5. Posso me utilizar de resultados de teste para quantificar minha

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

Referncias Bibliogrficas usadas

Testing Computer Software, 2nd ed.

Just Enough Software Test Automation

Delmaro, Mrcio Eduardo; Maldonado, Jos Carlos;

O livro uma importante aquisio para os

Referncias da Certificao ALATS

ALATS Associao Latino Americana de Teste

Referncias para pesquisa:

Teste de Software (primeira definio)

Padro IEEE (1983) IEEE Std 729-1983 Standard Glossary of Software

failure (falha) ocorre quando o programa apresenta algum problema

fault (defeito) o que existe no programa

Um defeito pode provocar uma falha no programa

error: (erro) uma ao humana que resulta em um defeito.

Termos e Definies III

Programao cdigo Uso / Operao

erro defeito falha

Vamos voltar ao assunto mais tarde ao analisar o processo de

Um software est correto se

1. Quando o software no faz algo que foi especificado,

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

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

5. O software difcil de entender, usar, lento ou, sob os olhos de quem

Famosos Erros de Software famosos

Bug do Ano 2000,

Jogo Lion King da Disney

Qual a origem dos bugs?

Os erros do cdigo so eliminados, em geral, na compilao.

MF = 0,5PR + 0,2EX + 0,3*SE