2º SEMESTRE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELETRÔNICA E COMPUTAÇÃO – PG/EEC-I –...

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELETRÔNICA E COMPUTAÇÃO – PG/EEC-I – ITA

2º SEMESTRE 2013

CE - 229 Teste de Software - Aula 02-1

CE-229 - Profs. Vieira Dias, Cunha e Lineu (c)

Técnicas de Caixa Preta

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)

2.1a.1/26

Técnicas de Caixa Preta

• Teste de Classe de Equivalência• Teste de Valor Fronteira• Teste de Tabela de Decisão• Pairwise Testing• Teste de Mudança de Estado• Teste de Análise de Domínio• Casos de Teste (Ivar Jacobsen*)• User Stories

CE-229 - Profs. Vieira Dias, Cunha e Lineu (c) 2.1a.2/26

O Processo de Teste


Entradas Processamento

OráculoSucesso ou Falha

Especificação do programa

Teste de Caixa Preta


O Processo de Teste

• Não é só para descobrir bugs de programação!• Procura ver se o software PROPICIA FAZER o

que o designer (arquiteto-projetista) propôs• No caso de teste de caixa preta é fundamental

que haja uma ótima definição dos requisitos (funcionais, principalmente e não funcionais) e/ou User Stories, uma vez que o teste é feito em função deles

• O testador não precisa conhecer em detalhes as entranhas do programa


Definição e Aplicabilidade

• Definição Caixa Preta – É uma estratégia de teste baseada apenas nos requisitos e/ou user stories e especificações.

• Aplicabilidade – Em todos os níveis de teste do software:

• Unidade• Integração• Sistema• Aceitação (do Produto)


TESTE DE CAIXA PRETA


Requisitos

Passou!

Caixa preta Falhou!

ResultadoEsperado?

Saídas

SIM

NÃO

Oráculo

Entradas

Processo de Teste Caixa Preta para SW sob teste (SW Under Test – SUT)

• Analisar requisitos e especificações• Escolher dados de entrada válidos e não

válidos, baseado nas specs (especificações)• Checar se as saídas são as esperadas• As saídas são comparadas com os

resultados esperados, tanto para dados válidos, como para não válidos


O Processo de Teste de Caixa Preta


Entradas Processamento

OráculoSucesso ou Falha

Especificação do programa

Vantagens da Caixa Preta• O testador é levado a selecionar conjuntos de

dados relevantes para o teste que sejam eficientes e eficazes para detetar defeitos

• Estes conjuntos irão detetar mais defeitos do que um teste criado de forma randômica ou baseado no “sentimento” do testador

• Lembrar: exemplo bem sucedido da prática, nos USA! Microsoft após VISTA


Desvantagens da Estratégia de Caixa Preta

• Não se sabe quanto do SUT foi testado Exemplo: if (name==“Vdias” && numero==1234) {

enviecheque(Vdias); // de R$ 30.000 }

• Para achar todos os defeitos é preciso criar todas as combinações possíveis de dados de entrada

• Em sistemas que dependem de estados anteriores o teste tem que lembrar os dados de entrada e/ou saída anteriores!


Teste de Classe de Equivalência (1/2)

• Definição – É uma estratégia que procura identificar classes (conjuntos) de dados que cubram uma parte representativa do SUT.

• Com isso consegue-se uma redução substancial no número de Casos de Teste

• É uma maneira intuitiva de testar


Teste de Classe de Equivalência (2/2)

• Exemplo: Uma empresa emprega pessoal com as seguintes limitações etárias (calma pessoal, eu sei que há inconsistências!):

• 0 a16 – Não contrata• 16 a18 – Só como estagiário(a)• 18 a 55 – Contrata CLT• 55 a 99 – Não contrata


Teste de Classe de Equivalência (3)

• Em vez de testar cada idade, testa-se uma idade em cada intervalo

• Exemplos: John, 17 – Estagiário

Peter, 34 – CLT

Britney, 18 – ???

Vera Ficher, 59 – Não contrata

Niemayer, 104 - ???


Como testar?

• Sem Classes de Equivalência: Força bruta (escolhe todas as idades: 0 a 99)

• Com classes de equivalência: Escolhe-se um “range” (intervalo) de idadesEx: if (idade >= 18 && idade <= 55 )

contrataCLT( );

• Usa-se dados de teste dentro do range


Perigo!

• Exemplo (difícil de detetar com Caixa Preta):

…

if (idade >= 18 && idade <= 51) contrata( );

if (idade == 51 && nome ==“Marcos”) ContrataSalarioExcessivo( );

if (idade == 51 && nome <> “Marcos”) contrata ( );

if (idade >= 51 && Idade <= 55) contrata( );

…CE-229 - Profs. Vieira Dias, Cunha e Lineu (c) 2.1a.16/26

Lembrete: Teste em Nível de Maturidade 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. A geração do código á feita de tal forma que facilte a tarefa de testar e de preparar o teste. O software resultante apresenta risco menor (Copeland, 2007)


Como testar com Classes de Equivalência

1 – Identifica-se a Classe de Equivalência

2 – Cria-se um caso de teste para cada classe de equivalência

3 – Casos de teste adicionais podem ser criados, para que você se sinta mais confortável, mas raramente eles descobrirão defeitos adicionais


Escolha de dados de entrada (contratos)

Deve-se testar entradas não válidas? Depende• 962• &$#!@• Ronaldinho

• Depende do contrato• Testa-se apenas o que o contrato exige (senão

sai muito caro!): pré-condições (estado anterior ao teste) e pós-condições do contrato (estado posterior).


Escolha de dados de entrada (contratos)

• As classes de equivalência podem ser:• contínuas• discretas

• Pode-se testar vários dados em um simples caso de uso de teste


Cheque de crédito para compra de apartamento próprio

Renda (R$) Numero APs Candidato Tipo AP Resultado

465 1 Pessoa Fis Apart Hotel Invalido

4622 2 Pessoa Fis Apart Res Inválido

3712 1 Pessoa Fis Cobertura OK

13020 1 Pessoa Jur Apart Res Inválido


Condições:1 – Renda > R$ 25002 – Máximo Aps = 13 – Tipo AP <> casa4 – Candidato = Pessos Física

Casos de Teste

• Ivar Hjalmar Jacobsen criou os Casos de Teste, no contexto do Processo Unificado da IBM-Rational (RUP)

• Exemplo que ciência dá dinheiro, pelo menos nos paises desenvolvidos


Ivar Hjalmar Jacobsen (1/3) (nota histórica)

• Ivar Hjalmar Jacobson (born in Ystad, Sweden, on September 2, 1939) is a Swedish Computer Scientist. He got his Master of Electrical Engineering at Chalmers Institute of Technology, in Gothenburg in 1962 and a Ph.D. at the Royal Institute of Technology, in Stockholm in 1985

Referência: JACOBSEN, I. et al. “Object-Oriented System Engineering: A Use Case Driven Approach”. New York, NY: Addison-Wesley, 1992


Ivar Hjalmar Jacobsen (2/3)• In 1967 he proposed the use of Software Components in the

development of the new generation of software controlled telephone switches Ericsson was developing

• At Ericsson he also invented Use Cases (Casos de Uso ≠ Estudos de Caso)

• In October 1995, Ericsson divested (vendeu) the SW Objectory to Rational Software, and Ivar started working with Grady Booch and James Rumbaugh, to first create the UML, and later develop the Rational Unified Process (RUP)

• Rational was bought by IBM in 2003 and Ivar decided to quit, but he stayed on until May 2004 as an executive technical consultant


Ivar jacobsen (3/3)(www.wikipedia.com)

• In mid 2003 Ivar formed Ivar Jacobson International (IJI) which is an umbrella company for Ivar Jacobson Consulting (IJC), which operates across 4 continents with offices in the UK, US (West and East Coasts), Scandinavia, China, Korea, Singapore and Australia.


Exercício: Criar um Oráculo com base no exemplo abaixo

Renda (R$) Numero APs Candidato Tipo AP Resultado

465 1 Pessoa Fis Apart Hotel Invalido

4622 2 Pessoa Fis Apart Res Inválido

3712 1 Pessoa Fis Cobertura OK

13020 1 Pessoa Jur Apart Res Inválido


Condições:1 – Renda > R$ 25002 – Máximo Aps = 13 – Tipo AP <> casa4 – Candidato = Pessos Física

2º SEMESTRE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELETRÔNICA E COMPUTAÇÃO – PG/EEC-I –...

Documents

Transcript of 2º SEMESTRE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELETRÔNICA E COMPUTAÇÃO – PG/EEC-I –...