A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

2º SEMESTRE 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.

Apresentações semelhantes


Apresentação em tema: "2º SEMESTRE 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."— Transcrição da apresentação:

1 2º SEMESTRE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELETRÔNICA E COMPUTAÇÃO – PG/EEC-I – ITA 2º SEMESTRE 2013 CE Teste de Software - Aula 02-1 CE Profs. Vieira Dias, Cunha e Lineu (c) Técnicas de Caixa Preta Vieira Dias (ITA) Prof. Dr. Luiz Alberto Vieira Dias (ITA) Cunha (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

2 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 Profs. Vieira Dias, Cunha e Lineu (c)2.1a.2/26

3 O Processo de Teste CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.3/26 EntradasProcessamento Oráculo Sucesso ou Falha Especificação do programa

4 Teste de Caixa Preta CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.4/26

5 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 CE Profs. Vieira Dias, Cunha e Lineu (c) 2.1a.5/26

6 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) CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.6/26

7 TESTE DE CAIXA PRETA CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.7/26 Requisitos Passou! Caixa preta Falhou! Resultado Esperado? Saídas SIM NÃO Oráculo Entradas

8 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 CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.8/26

9 O Processo de Teste de Caixa Preta CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.9/26 EntradasProcessamento Oráculo Sucesso ou Falha Especificação do programa

10 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 CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.10/26

11 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$ } 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! CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.11/26

12 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 CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.12/26

13 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 CE Profs. Vieira Dias, Cunha e Lineu (c) 2.1a.13/26

14 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, ??? CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.14/26

15 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 idades Ex: if (idade >= 18 && idade <= 55 ) contrataCLT( ); Usa-se dados de teste dentro do range CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.15/26

16 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 Profs. Vieira Dias, Cunha e Lineu (c)2.1a.16/26

17 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) CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.17/26

18 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 CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.18/26

19 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). CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.19/26

20 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 CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.20/26

21 Cheque de crédito para compra de apartamento próprio Renda (R$)Numero APsCandidatoTipo APResultado 4651Pessoa FisApart HotelInvalido 46222Pessoa FisApart ResInválido 37121Pessoa FisCoberturaOK Pessoa JurApart ResInválido CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.21/26 Condições: 1 – Renda > R$ – Máximo Aps = 1 3 – Tipo AP <> casa 4 – Candidato = Pessos Física

22 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 CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.22/26

23 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 CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.23/26

24 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 CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.24/26

25 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. CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.25/26

26 Exercício: Criar um Oráculo com base no exemplo abaixo Renda (R$)Numero APsCandidatoTipo APResultado 4651Pessoa FisApart HotelInvalido 46222Pessoa FisApart ResInválido 37121Pessoa FisCoberturaOK Pessoa JurApart ResInválido CE Profs. Vieira Dias, Cunha e Lineu (c)2.1a.26/26 Condições: 1 – Renda > R$ – Máximo Aps = 1 3 – Tipo AP <> casa 4 – Candidato = Pessos Física


Carregar ppt "2º SEMESTRE 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."

Apresentações semelhantes


Anúncios Google