Aula 3 - Lineu FS Mialaret

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA
ELETRÔNICA E COMPUTAÇÃO – PG/EEC-I – ITA
2º SEMESTRE 2013
Introdução ao Teste de Software
CE - 229 Teste de Software - Aula 01-2
Prof. Dr. Luiz Alberto Vieira Dias (ITA)
Prof. Dr. Adilson Marques da Cunha (ITA)
Prof. Dr. Lineu Mialaret (ITA/IFSP)
Colaboração:
Renan Cavichi (Aluno MSc, ITA/IFSP)
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.1/19
Qualidade, Confiabilidade e
Segurança (Safety) [Cunha, 2012]
• Qualidade – Conformidade com requisitos
• Confiabilidade – Qualidade no tempo
• Safety – Confiabilidade no uso
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.2/19
Defeitos, Erros, Falhas em Software
[Cunha,2012]
(DEF)
• Engano* – Ação humana que produz o defeito
• Defeito – Imperfeição ou anomalia que pode causar
uma inadequação ou falha no SW
• Erro – Manifestação de um Defeito
• Falha – Manifestação de um Defeito, que causa uma
operação defeituosa no SW
(*) Pouco utilizado
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.3/19
O Processo de Teste
• “Testar é o processo de comparar “o que é”
com “o que deveria ser”
• De acordo com o IEEE Standard Glossary of
Software Engineering Terminology, (610.12 1990) Testar é:
“ O processo de operar um sistema ou
componente sob condições especificadas,
observando (e/)ou registrando os resultados,
enquanto avalia o sistema ou componente
sob algum aspecto”.
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.4/19
O Processo de Teste
Especificação
do programa
Entradas
Oráculo
Sucesso
ou Falha
Processamento
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.5/19
Níveis de Maturidade de Teste – Nível 0
Neste nível, não há diferença entre testar e
debugar. O “teste” não tem propósito determinado.
Registro do primeiro
“bug”de computador
•
“In 1946, when Rear Admiral Grace Hopper was released from active duty, she joined the
Harvard Faculty at the Computation Laboratory, where she continued her work on the Mark II
and Mark III. Operators traced an error in the Mark II to a moth trapped in a relay, coining the
term bug. This bug was carefully removed and taped to the log book” (www.wikipedia.com)
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.6/19
Nível 1
• O propósito do Teste é mostrar que o SW
funciona (não falha)
• O conjunto de dados de teste pode ser
escolhido de tal forma que o SW funciona
para ele, mas pode falhar para outro conjunto
• Este tipo de teste (muito comum quando se
quer vender algo!) pode não propiciar a
descoberta de Defeitos (D)
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.7/19
Nível 2
• O propósito é mostrar que o SW não
funciona, para algum conjunto de dados
• Normalmente o conjunto de dados de teste
escolhido procura checar o envelope
(fronteira) do sistema
• O sistema pode funcionar para algum
conjunto menos exigente de dados
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.8/19
Nível 3
• O propósito do Teste não é mostrar que o
SW funciona ou não funciona, mas reduzir o
risco percebido, caso ele não funcione para
algum conjunto de valores
• Deve ser notado que embora o caso ideal
seja testar todas as possibilidades, isto não
é fisicamente possível
• Paradoxo do Teste de SW: “Em geral, não é
possível testar todas as possibilidades”
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.9/19
Nível 4
• Testar, neste nível, não é um simples ato
• É uma disciplina mental que resulta em SW
de baixo risco, com pouco esforço de teste
• Neste nível de maturidade o SW é testado
desde sua concepção  Ver aula de hoje!
• A geração do código é feita de tal forma que
facilite a tarefa de testar e de preparar o teste
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.10/19
Paradoxos do Teste
• Em geral, não é possível testar todas as
possibilidades
• Deve-se testar o mínimo necessário e suficiente
Apesar das assertivas acima, o resultado deve
conduzir ao menor risco, possível de se ter
defeitos e/ou falhas no SW
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.11/19
Desafios
•
•
•
•
•
•
Pouco tempo para testar adequadamente
Muitas combinações de entrada
Dificuldade de determinar a saída correta (oráculo)
Requisitos não existentes ou variáveis
Falta de ferramenta de teste
Gerência que não entende ou (aparentemente) não
se importa com a qualidade do SW
• Falta de tempo para testar adequadamente
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.12/19
Casos de Teste
• Os mais efetivos e eficientes Casos de Teste
devem ser projetados e não simplesmente
agrupados
• Segundo Pressman [1982]: “O Teste tem que ter
a máxima probabilidade de se achar a maioria
dos erros, com o mínimo esforço, no menor
tempo possível”
(*)PRESSMAN, R.S. Software Engineering: A Practitioner’s
Approach. 7th Ed. New York, NY: McGraw-Hill, 2009
•
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.13/19
Casos de Teste (2)
• Um Caso de Teste bem projetado é
composto de pelo menos 3 partes:
• Entradas
• Saídas
• Ordem de execução
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.14/19
Oráculo
• Em projetos de Casos de Teste, determinar as saídas
esperadas é função do ORÁCULO
• Um oráculo é qualquer programa, processo ou dados
(tabela) que propicie ao testador a saída esperada
resultante de um teste
• Tipos de Oracúlos:
1.
2.
3.
4.
Kiddie: roda e vê o que dá
Teste de regressão: roda e compara com versão anterior (prog =)
Dados validados: roda e compara com padrões (tabelas)
Suites de Teste padrão: checa contra resultados validados (em geral dados
comprados de empresas especializadas em testes)
5. Programa existente: roda e compara com outra versão (prog < >)
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.15/19
Ordem de execução
• Cascata* – o resultado de um teste é a
entrada do próximo
• Independente – os casos de teste podem
rodar independentemente
(*) Não confundir com a Metodologia Cascata de
desenvolvimento de software
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.16/19
Tipos de Teste
• Caixa preta (Funcional) – Baseado nos requerimentos
e especificações. Uma boa especificação é
fundamental neste caso. Não requer grande habilidade
de programação do testador (?)
• Caixa branca (Estrutural) – Baseado na estrutura
interna do programa. O testador precisa ter grande
habilidade em programação
• Caixa Cinza – combinação dos anteriores
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.17/19
Níveis de Teste
•
•
•
•
Teste de Unidade
Teste de Integração
Teste de Sistema
Teste de Aceitação:
– Quem cria os casos de teste?
( ) Testador ( ) Desenvolvedor ( ) Cliente
– Quem executa o teste
( )Testado ( ) Desenvolvedor ( ) Usuário
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.18/19
Resumo
• Nível de Maturidade de Teste de Software:
•1a5
• Tipos de Teste:
• Caixa Preta e Caixa Branca
• Níveis de Teste:
• Unidade
• Integração
• Sistema
• Aceitação
CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)
1.1b.19/19