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