Verificação, Validação e Testes: Teste de Software

Transcrição

1 CEDESC Curso de Especialização em Desenvolvimento de Software PETROBRAS Verificação, Validação e Testes: Teste de Software Guilherme Horta Travassos Grupo de Engenharia de Software Experimental Roteiro Módulo I: Conceitos e Definições de Teste de Software Módulo II:Técnicas de Teste de Software Módulo III: Estratégias para Projeto e Execução dos Testes Módulo IV: Planejamento e Controle de Testes de Software

2 Módulo I Conceitos e Definições de Teste de Software Módulo I: Roteiro Conceitos Básicos de Teste de Software em Geral Elementos do Teste de Software Mitos associados às Atividades de Teste de Software Níveis de Teste Desenvolvimento x Teste de Software Testes de Software em Normas e Modelos de Maturidade de Processo

3 Definições Garantia de Qualidade de Software Verificação: Assegurar consistência, completude e corretude do produto em cada fase e entre fases consecutivas do ciclo de vida do software. Estamos construindo corretamente o produto?. Validação: Assegurar que o produto final corresponde aos requisitos do software. Estamos construindo o produto correto?. Teste: Examina o comportamento do produto através de sua execução. Falta (Fault): Definições É inserida no software quando um desenvolvedor comete algum equívoco. Um equívoco pode causar várias faltas ao mesmo tempo que vários enganos pode causar uma falta idêntica. Falha (Failure): Representa um comportamento incorreto apresentado por um software em conseqüência de uma falta. Erro (Error): Representa o quanto um resultado é incorreto. Defeito (Defect): Termo genérico para falta, falha ou erro.. IEEE , A Glossary of Software Engineering Terminology in Schach, S.R. (2008). Introduction to Object-Oriented Software Engineering. McGraw-Hill

4 Teste e Depuração Teste: Processo de executar um software ou sistema com o objetivo de revelar a presença de falhas; ou, falhando nesse objetivo, aumentar a confiança sobre o software Depuração: é uma conseqüência não previsível do teste. Após revelada a presença do erro, o defeito deve ser encontrado e corrigido Depuração não é teste! Elementos do Teste de Software Caso de Teste: Descreve uma condição particular a ser testada. Composto por valores de entrada, restrições para a sua execução e um resultado ou comportamento esperado. Procedimento (Roteiro) de Teste: Descreve os passos necessários para a execução de um ou um grupo de casos de teste Critérios de Cobertura dos Testes: Permitem a identificação de partes do programa que devem ser executadas para garantir a qualidade do software e indicar quando o mesmo foi suficientemente testado. A Cobertura dos Testes determina o percentual de elementos testados em um programa.

5 Elementos do Teste de Software Rodada (Bateria) de Teste: Consiste na execução de todos os procedimentos de teste para uma versão do produto em um determinado ambiente de teste Uma nova rodada de teste deve ser executada caso o critério de aceitação do produto não tenha sido atingido Incidentes de Teste: Qualquer evento ou comportamento diferenciado que ocorra durante a execução dos testes que requer futura investigação Não há garantia que todo incidente seja uma falha, pois ainda precisa ser analisado Defeitos no Desenvolvimento de Software Quanto antes a presença do defeito for revelada, menor o custo de correção do defeito e maior a probabilidade de corrigi-lo corretamente Principal causa: Tradução incorreta de informações Solução: Introduzir atividades de VV&T ao longo de todo o ciclo de desenvolvimento

6 Mitos Associados a Testes e Requisitos (1) Mito: Não é possível testar até que o sistema exista... Fatos: Testar é muito mais do que apenas ver o que vai acontecer E muito mais que apenas executar casos de teste! Documentos de requisitos podem e devem ser testados em relação aos objetivos do negócio ou projeto para assegurar completude e correção Mitos Associados a Testes e Requisitos (2) Mito: Desenvolvedores devem pensar nos requisitos apenas no início do desenvolvimento, e se preocupar com testes apenas no final... Fatos: Ter os testadores envolvidos durante a análise de requisitos é uma das melhores formas de se assegurar requisitos de boa qualidade Trocas tardias nos requisitos causam impacto nos testes Ter os usuários envolvidos nos requisitos e nos testes é fundamental!

7 Mitos Associados a Testes e Requisitos (3) Mito: Requisitos são utilizados no teste, mas não o contrário... Fatos: Você não testa requisitos, mas testa a partir deles! É fácil escrever requisitos pouco vagos ou ambíguos, que parecem estar ok. Quando bons testadores observam a especificação de requisitos, eles aconselham casos de teste específicos para acertar os requisitos vagos, ambíguos ou não muito explícitos. Boa engenharia de requisitos produz melhores testes; boa análise de testes melhora os requisitos! Mitos Associados a Testes e Requisitos (4) Mito: Se escrever testes é difícil, isto é somente um problema dos testadores... Fatos: Nem todos os requisitos são criados de acordo com a mesma perspectiva do testador. Para alguns dos requisitos fica fácil definir o teste, para outros um verdadeiro pesadelo! Especificar requisitos não funcionais testáveis tais como usabilidade ou desempenho é difícil Frases como fácil de usar, interface amigável, muito confiável ou desempenho aceitável não representam especificação de requisitos!

8 Mitos Associados a Testes e Requisitos (5) Mito: Não se preocupe, pequenas modificações nos requisitos não afetarão os testes Fatos: Uma modificação aparentemente pequena nos requisitos pode trazer grande impacto para os testes Você deve testar todas as modificações para confirmar que o sistema está executando corretamente. É possível que testes de regressão sejam necessários O esforço do teste face a modificação vai depender dos riscos associados à modificação e dos impactos conhecidos (e desconhecidos!) no sistema Mitos Associados a Testes e Requisitos (6) Mito: Os testadores não precisam dos requisitos Fatos: O sistema deve apoiar o negócio a atingir um objetivo, então o que o sistema realmente faz deve ser comparado com este objetivo Uma especificação de requisitos representa o oráculo para o teste! Sim, testadores precisam dos requisitos, caso contrário, você poderia argumentar que o que vem sendo executado não é realmente um teste!

9 Mitos Associados a Testes e Requisitos (7) Mito: Os testadores não podem testar sem os requisitos Fatos: Este é também um mal entendido comum Algumas vezes modificações são realizadas nos sistemas onde requisitos são inadequados ou não existentes. Isto faz o teste ser mais difícil, mas não é possível dizer que não pode ser feito Aplicar teste exploratório pode ser uma saída Objetivo dos Testes de Software Refutar a assertiva de que o produto está correto Determinar entradas que façam as saídas obtidas diferirem das saídas esperadas de acordo com a especificação (busca de um contra-exemplo) É um processo destrutivo, sob o ponto de vista psicológico, contrariamente às demais fases da Engenharia de Software, onde constrói-se um produto

10 Características dos Testes de Software Uma das atividades mais onerosas do desenvolvimento de software Último recurso para avaliação do produto antes de sua entrega ao usuário final Atividade essencial para ascensão ao nível 3 do CMMI e Nível D do MPS Atividade relevante para avaliação de produtos de software (ISO 9126, ISO ) Princípios de Teste de Software Os testes devem ser rastreáveis aos requisitos do usuário devem ser realizados para testar os requisitos do usuário Devem ser completamente planejados antes de seu início. O planejamento é primordial para sua execução O princípio de Paretto se aplica: 80% de todos os erros encontrados a partir das falhas reveladas estarão concentrados em 20% dos componentes do software

11 Princípios de Teste de Software Devem ser aplicados inicialmente em pequena escala e depois expandidos Não é possível aplicá-los exaustivamente Para aumentar sua eficácia, deve ser executado por equipes independentes (quem não desenvolveu o software) Para evitar viés na execução, os testadores devem ser diferentes daqueles que planejaram os testes Teste de Software O que identifica um bom teste? Possui alta probabilidade de revelar falhas Não é redundante É abrangente o suficiente Possui um nível adequado de complexidade

12 Testabilidade de Software Simplesmente tenta mostrar a facilidade com que um software pode ser testado Operação quanto melhor funciona, mais eficientemente pode ser testado Observação o que você vê é o que você testa Controle quanto melhor podemos controlar o software, mais podemos automatizar e melhorar o teste Testabilidade de Software Decomposição Controlando o escopo do teste, podemos mais rapidamente isolar os problemas e executar re-teste adequado Simplicidade Quanto menos existe para se testar, mais rapidamente podemos testar o software Estabilidade Quanto menos modificações, menos problemas para testar Compreensão quanto mais informação tivermos, mais adequado será o teste

13 Teste de Software Não ocorrência de falha: Software é de alta Qualidade? OU Teste é de baixa Qualidade? Teste de Software Defeitos e erros "emboscados" no software e não revelados Falhas a se manifestarem na utilização pelos usuários e defeitos corrigidos durante a manutenção. CUSTOS ALTÍSSIMOS!

14 Teste de Software Custos resultantes de testes insuficientes: US$ 22.2 a 59.5 bi (NIST, National Institute of Standards and Technology,Maio 2002) Atividade que tipicamente envolve: Execução do software com entradas representativas para as futuras condições de operação Comparação entre saídas produzidas e esperadas Comparação entre estados resultantes e esperados Mensuração de características de execução (memória e tempo consumidos,etc.) Teste de Software Se falhas graves se manifestam torna-se necessária a modificação do projeto, se erros são encontrados com regularidade colocam Qualidade e confiabilidade sob suspeita revelando a necessidade de NOVOS TESTES!

15 Teste de Software Defeitos de fácil correção indicam que as funções aparentemente funcionam bem. Qualidade e confiabilidade aceitáveis, ou testes inadequados para revelar a ocorrência de falhas graves? Teste de Software Estratégias para Teste Unidade Integração Sistema Re-Teste Regressão Fumaça Aceitação Instalação código Projeto Requisitos Alta ordem Unidade Integração

16 Teste de Software Unidade Integração Perspectiva dos projetistas/desenvolvedores Funcional Não-Funcional Aceitação Perspectiva do Cliente/Usuário Instalação Infra-Estrutura para Teste Driver Componente a ser testado Interface Estruturas de Dados Locais Condições Limites Caminhos Independentes Caminhos de tratamento de erros Stub Stub Casos de Teste Resultados

17 Teste de Unidade É a fase do processo de teste em que se testam as menores unidades de software desenvolvidas O universo alvo desse tipo de teste são os métodos dos objetos ou mesmo pequenos trechos de código Objetivo: encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo Existem situações em que você não terá os recursos para realizar o teste completo das unidades. Selecione os módulos críticos e aqueles com alta complexidade e apenas teste estes módulos Utilize inspeções de código Teste de Integração "Se todos os módulos funcionam individualmente (analisado através do teste de unidade), por que se tem dúvida de que eles funcionarão quando colocados juntos? O problema é exatamente "colocá-los juntos" tendo uma interface. Teste de Integração Fase destinada à construção da estrutura do programa, realizandose, ao mesmo tempo, testes para descobrir erros associados a interface A partir dos módulos testados no nível de unidade, construir a estrutura de programa que foi determinada pelo projeto Além disso, encontrar falhas provenientes da integração interna dos componentes de um sistema Tipos de falhas: envio e recebimento de dados Ex: Por exemplo, um objeto A pode estar aguardando o retorno de um valor X ao executar um método do objeto B, porém este objeto B pode retornar um valor Y, desta forma gerando uma falha

18 Teste de Integração Aplicar a abordagem big bang para integração é uma estratégia ingênua que está fadada ao fracasso. Teste de integração deve ser conduzido de forma incremental e organizada! Top-Down Quando você desenvolve um cronograma detalhado para o projeto você tem que considerar a maneira na qual a integração de componentes ocorrerá de forma que os componentes estejam disponíveis quando necessários Bottom-up Integração bottom-up elimina a necessidade de stubs complexos Teste de Sistema Objetivo: executar o sistema sob ponto de vista de seu usuário final, varrendo as funcionalidades em busca de falhas Testes executados em condições similares (de ambiente, interfaces sistêmicas e massa de dados) àquelas que um usuário utilizará no seu dia-a-dia Um sistema divide-se em características Funcionais e Não- Funcionais: Funcional: Ignora a estrutura do sistema Foco na funcionalidade Não-Funcional Considera as características de qualidade do sistema: Usabilidade, Portabilidade, Recuperabilidade, Segurança, Eficiência,... Sistema = Funcional + Não-Funcional

19 Teste de Sistema Tipos específicos de Teste de Sistema: Recuperação força o software a falhar numa variedade de situações e verifica a capacidade de recuperação do produto Segurança verifica se os mecanismos de proteção construídos para o sistema irão de fato protegê-lo de alguma utilização ou intrusão imprópria. Stress executa o sistema de forma a exigir recursos em quantidade, freqüência ou volume anormais Desempenho avalia o desempenho do software quando integrado ao sistema. Normalmente está associado ao teste de stress Estratégias para Re-Teste Podem ocorrer para qualquer estratégia de teste, em caso de mudanças no software no planejamento dos testes Dois tipos: Regressão Teste de regressão é uma estratégia importante para redução de efeitos colaterais. Consiste em se aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. Execute testes de regressão toda vez que uma modificação maior é realizada no software (incluindo a integração de novos módulos) Efetue a gerência de configuração Fumaça (smoke testing) Teste fumaça pode ser caracterizado como estratégia de integração incremental. O software é reconstruído (com novos componentes incorporados) e exercitado diariamente.

20 Teste de Aceitação Assim como os outros tipos de teste, validação tenta descobrir erros, mas o foco está nos requisitos - nas características que estarão imediatamente aparentes para o usuário final Os testes são realizados, geralmente, por um grupo restrito de usuários finais do sistema Teste formal conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação e para permitir ao cliente determinar se aceita ou não o sistema. Critérios para Teste de Aceitação 1. A funcionalidade (caso de uso) ou características de desempenho estão de acordo com o especificado e são aceitas 2. Uma variação da especificação é descoberta e uma lista de discrepâncias (deficiências) é criada Teste de Aceitação Revisão da Configuração Assegura que todos os elementos da configuração de software foram propriamente desenvolvidos, estão catalogados e possuem o nível de detalhe suficiente para serem utilizados durante o ciclo de vida do software Algumas vezes identificada como auditoria. Teste Alfa e Beta Alfa: executado na instalação do desenvolvedor pelo cliente Beta: executado na instalação de um ou mais clientes pelo usuário final do software

21 Teste de Instalação Consiste em instalar o sistema nos locais em que estão os usuários Dispensado no caso do teste de aceitação ter sido executado no ambiente do usuário Focam: A integridade do sistema instalado; e A verificação quanto a se alguma característica funcional ou não funcional foi afetada pelas condições do local de operação Desenvolvimento x Testes Requisitos do Sistema Teste de Aceitação Requisitos do Software Teste de Sistema Modelo de Projeto Teste de Integração Código Teste de Unidade Projeto dos Testes Execução dos testes

22 Teste de Software em Normas e Modelos de Maturidade de Processos ISO Norma para definição de processos de ciclo de vida de software Objetivo é auxiliar na definição de processos de software organizacionais ISO SPICE Padrão internacional para Avaliação de Processo de Software inspirada pelo Software CMM e ISO 9001 Objetivo de harmonizar diferentes modelos (Software CMM, CMMI, ISO 9001, ISO e Bootstrap) CMMI e MPS Modelos para estabelecimento de padrão de qualidade para processos de software Recomendações: Teste de Software Convide os testadores a participar das revisões dos requisitos e inspeções Comece o planejamento do teste em paralelo com a análise de requisitos Inclua sugestões de condições de teste e casos de teste para utilizar como exemplos na especificação de requisitos Inclua no documento de requisitos qualquer caso específico que vier a mente quando estiver analisando os requisitos Utilize cenários de negócios e casos de uso para dar exemplos específicos de como o sistema deveria funcionar Identifique critérios mensuráveis para ambos os tipos de requisitos (funcionais e não funcionais)...

23 Módulo II Técnicas de Teste de Software Módulo II: Roteiro Projeto de Casos de Teste Critérios de Teste Técnicas de Teste: Funcional x Estrutural x Baseada em Erros Exercícios de Fixação

24 Projeto de Casos de Teste Projeto de teste pode ser tão difícil quanto o projeto do próprio produto a ser testado Poucos programadores/analistas gostam de teste; menos ainda de projeto de casos de teste Projeto de teste é um dos melhores mecanismos para prevenção de defeitos O projeto de casos de teste é tão eficaz em identificar erros quanto a execução dos casos de teste projetados Funciona como uma forma de revisão! Projeto de Casos de Teste Esteja certo que você projeta testes para executar todo caminho de tratamento de erro Senão, o caminho pode falhar quando ativado, revelando uma situação nem sempre agradável do sistema Existem algumas situações nas quais você não terá todos os recursos para realizar um teste completo das unidades Selecione os componentes mais críticos e aqueles com alta complexidade ciclomática e teste inicialmente estes

25 Critérios rios de Teste Dados um programa P e um conjunto de casos de teste T, definem-se: Critério de Seleção de Casos de Teste: procedimento para escolher casos de teste para o teste de P. Critério de Adequação de Casos de Teste: predicado para avaliar T no teste de P; Existe uma forte correspondência entre critérios de seleção e de adequação de casos de teste Dado um critério de adequação C, existe um critério de seleção CS que estabelece: selecione T tal que T seja adequado a C Dado um critério de seleção CS, existe um critério de adequação C que estabelece: T é adequado se foi selecionado de acordo com CS Critério de Seleção de Casos de Teste É um método de escolha de casos de teste se obedecido, gera um conjunto de casos de teste capaz de identificar falhas causadas por uma determinada categoria de erros Um critério de seleção de casos de teste deve ser válido: acusa falhas sempre que existam erros no artefato sendo testado confiável: as falhas encontradas são indiferentes à escolha dos dados e das ações desde que satisfaçam as condições dos casos de teste completo: segundo um padrão de completude viável: Deve possuir um custo de aplicação razoável

26 Critério de Adequação de Casos de Testes Define quais propriedades precisam ser testadas para garantir inexistência de erros Como é impossível garantir inexistência de erros, o conceito é utilizado, na prática, para definir uma qualidade mínima que será validada pelo teste Objetivo:... obter, de maneira sistemática um conjunto T de casos de teste efetivo quanto à meta principal de teste revelar falhas no programa Propriedades: i) incluir todos os desvios de fluxo de execução ii) incluir pelo menos um uso de todo resultado computacional iii) T mínimo e finito T é C-adequado todo elemento requerido por C é exercitado por pelo menos um t, t T Técnicas para Teste de Software Técnicas: Funcional (ou caixa preta/caixa fechada) Estrutural (ou caixa branca/caixa aberta) Baseada em erros A questão não está em qual delas utilizar e sim como combiná-las de forma a maximizar os benefícios das atividades de teste!

27 Técnica Funcional Baseia-se na especificação do software para derivar os requisitos de teste Aborda o software de um ponto de vista macroscópico Envolve dois passos principais: identificar as funções que o software deve realizar (especificação dos requisitos, casos de uso) criar casos de teste capazes de verificar se essas funções estão sendo executadas corretamente Técnica Funcional Problema: Dificuldade em quantificar a atividade de teste - não se pode garantir que partes essenciais ou críticas do software foram executadas Critérios da Técnica Funcional: Particionamento em Classes de Equivalência Análise do Valor Limite Grafo de Causa-Efeito

28 Técnica Funcional Particionamento em Classes de Equivalência Divide o domínio de entrada do programa em classes de dados (classes de equivalências) os dados de teste são derivados a partir das classes de equivalência Eventualmente, pode se considerar o domínio de saída como referência (ex. relatórios) Técnica Funcional Particionamento em Classes de Equivalência Dois Passos: Identificar classes de equivalência (é um processo heurístico) condição de entrada válidas e inválidas Definir os casos de teste enumeram-se as classes de equivalência casos de teste para as classes válidas casos de teste para as classes inválidas

29 Técnica Funcional Particionamento em Classes de Equivalência Método caixa-preta que divide o domínio de entrada de um sistema em classes (categorias) de dados das quais casos de teste podem ser derivados Força a definição de um caso de teste que revela categorias de erros, desta forma reduzindo o número total de casos de teste que devem ser desenvolvidos Baseado na avaliação de classes de equivalência para uma condição de entrada Se um conjunto de objetos podem ser ligados por relacionamentos que são simétricos, transitivos e reflexivos, uma classe de equivalência está presente. Técnica Funcional Particionamento em Classes de Equivalência Uma classe de equivalência representa um conjunto de estados válidos e inválidos para uma condição de entrada. Tipicamente uma condição de entrada pode ser um valor numérico específico, uma faixa de valores, um conjunto de valores relacionados, ou uma condição lógica. Diretrizes: Se uma condição de entrada especifica uma faixa de valores ou requer um valor específico, uma classe de equivalência válida e duas inválidas são definidas; Se uma condição de entrada especifica um membro de um conjunto ou é lógica, uma classe de equivalência válida e uma inválida são definidas

30 Classe de Equivalência: Exemplo Especificação do programa Identifier: O programa deve determinar se um identificador é válido ou não em Silly Pascal (uma estranha variante do Pascal). Um identificador válido deve começar com uma letra e conter apenas letras ou dígitos. Além disso, deve ter no mínimo 1 caractere e no máximo 6 caracteres de comprimento. Exemplo: abc12 (válido); cont*1 (inválido); 1soma (inválido); a (inválido) BARBOSA, E.; MALDONADO, J.C.; VINCENZI, A.M.R.; DELAMARO, M.E; SOUZA, S.R.S. e JINO, M.. Introdução ao Teste de Software. XIV Simpósio Brasileiro de Engenharia de Software (disponivel em último acesso em 07/03/2007) Classe de Equivalência: Exemplo Classes de equivalência Condições de Entrada Classes Válidas Classes Inválidas Tamanho t do identificador Primeiro caractere c é uma letra Só contém caracteres válidos 1 t 6 (1) Sim (3) Sim (5) t > 6 (2) Não (4) Não (6) Exemplo de Conjunto de Casos de Teste T 0 = {(a1,válido), (2B3, Inválido), (Z-12, Inválido), (A1b2C3d, Inválido)}

31 Técnica Funcional Análise do Valor Limite Por razões não completamente identificadas, um grande número de erros tende a ocorrer nos limites do domínio de entrada invés de no centro Análise do Valor Limite é uma técnica de teste que explora os limites dos valores para preparar os casos de teste Está técnica complementa o particionamento em classes de equivalência Técnica Funcional Análise do Valor Limite - Diretrizes Se uma condição de entrada especifica uma faixa de valores limitadas em a e b, casos de teste devem ser projetados com valores a e b e imediatamente acima e abaixo de a e b; Se uma condição especifica um número de valores, casos de teste deveriam ser desenvolvidos para exercitar os números mínimo e máximo. Valores imediatamente acima e abaixo do mínimo e máximo são também testados Ex: A={1..10}; Casos de Teste => {1, 10, 0,11} Aplique as diretrizes 1 e 2 para as condições de saída. Por exemplo, assuma que uma tabela de temperatura x pressão é necessária como saída de um programa de análise de engenharia. Casos de teste deveriam ser projetados para criar um relatório de saída que produza o máximo (e mínimo) número possível de entradas na tabela; Se uma estrutura de dados interna do programa tem identificados seus limites (ex. Um vetor com 100 posições), esteja certo de projetar um caso de teste para exercitar a estrutura de dados em seu limite

32 Análise do Valor Limite: Exemplo Consideremos a seguinte situação: "... o cálculo do desconto por dependente é feito da seguinte forma: a entrada é a idade do dependente que deve estar restrita ao intervalo [0..24]. Para dependentes até 12 anos (inclusive) o desconto é de 15%. Entre 13 e 18 (inclusive) o desconto é de 12%. Dos 19 aos 21 (inclusive) o desconto é de 5% e dos 22 aos 24 de 3%..." Aplicando o teste de valor limite convencional serão obtidos casos de teste semelhantes a este: {-1,0,12,13,18,19,21,22,24,25} incluindo valores fora da faixa. Técnica Funcional Grafo de Causa-Efeito Técnica para identificação de casos de teste que explora as condições lógicas e as ações correspondentes. Basicamente, 4 passos devem ser executados: Para cada módulo, Causas (condições de entrada) e efeitos (ações realizadas às diferentes condições de entrada) são relacionados, atribuindo-se um identificador para cada um. Em seguida, um grafo de causa-efeito (árvore de decisão) é desenhado. Neste ponto, transforma-se o grafo numa tabela de decisão. As regras da tabela de decisão são, então, convertidas em casos de teste.

33 Grafo Causa-Efeito: Exemplo Causa: valor compra > 80 ^ #produtos < 3 Efeito: frete grátis >80 #produtos < 3 Frete Grátis Valor compra >=3 Árvore de Decisão <=80 Cobrar Frete Tabela de Decisão Causa Efeito Valor Compra >80 >80 <=80 #Produtos <3 >=3 -- Cobrar Frete V V Frete Grátis V Técnica Estrutural É baseada no conhecimento da estrutura interna da implementação Teste dos detalhes procedimentais A maioria dos critérios dessa técnica utiliza uma representação de programa conhecida como grafo de programa ou grafo de fluxo de controle

34 Programa Identifier.c /* 01 */ { /* 01 */ char achar; /* 01 */ int length, valid_id; /* 01 */ length = 0; /* 01 */ printf ("Digite um possível identificador\n"); /* 01 */ printf ("seguido por <ENTER>: "); /* 01 */ achar = fgetc (stdin); /* 01 */ valid_id = valid_starter (achar); /* 01 */ if (valid_id) /* 02 */ length = 1; /* 03 */ achar = fgetc (stdin); /* 04 */ while (achar!= '\n') /* 05 */ { /* 05 */ if (!(valid_follower (achar))) /* 06 */ valid_id = 0; /* 07 */ length++; /* 07 */ achar = fgetc (stdin); /* 07 */ } /* 08 */ if (valid_id && (length >= 1) && (length < 6) ) /* 09 */ printf ("Valido\n"); /* 10 */ else /* 10 */ printf ("Invalido\n"); /* 11 */ } BARBOSA, E.; MALDONADO, J.C.; VINCENZI, A.M.R.; DELAMARO, M.E; SOUZA, S.R.S. e JINO, M.. Introdução ao Teste de Software. XIV Simpósio Brasileiro de Engenharia de Software (disponivel em último acesso em 07/03/2007) Técnica Estrutural (Grafo de Programa) Detalhes considerados: nó arco caminho: simples completo livre de laço fluxo de controle Grafo de Programa do identifier.c Gerado pela View-Graph (USP-SC)

35 Técnica Estrutural (Grafo de Programa) Nós: blocos indivisíveis não existe desvio para o meio do bloco uma vez que o primeiro comando do bloco é executado, os demais comandos são executados seqüencialmente Arestas ou Arcos: representam o fluxo de controle entre os nós Critérios da Técnica Estrutural: Técnica Estrutural Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger - Prentice Hall- Cap. 08

36 Técnica Estrutural Critérios de Fluxo de Controle Todos-Nós: 1,2,3,4,5,6,7,8,9,10,11 Todos-Arcos: arcos primitivos: <1,2>,<1,3>,<5,6>,<5,7>, <8,9>,<8,10> Todos-Caminhos Grafo de Programa do identifier.c Gerado pela View-Graph (USP-SC) Técnica Baseada em Erros Os requisitos de teste são derivados a partir dos erros mais freqüentes cometidos durante o processo de desenvolvimento do software Critérios da Técnica Baseada em Erros: Semeadura de Erros Análise de Mutantes (teste de unidade) Mutação de Interface (teste de integração)

37 Análise de Mutantes Garantir a ausência de determinados tipos de defeitos Considerando todos os programas Q, é possível provar a correção de P T P Q t T P(t) Q(t) É impraticável executar e comparar todos os programas Q Estabelece-se então uma vizinhança Φ(P) que contém apenas um conjunto finito de programas Esses programas contêm pequenos desvios sintáticos que representam defeitos simples Análise de Mutantes Hipótese do Programador Competente Programadores experientes escrevem programas corretos ou muito próximos do correto Efeito de Acoplamento Casos de teste capazes de revelar erros simples são tão sensíveis que, implicitamente, também são capazes de revelar erros mais complexos

38 Análise de Mutantes Os operadores de mutação determinam o tipo de alteração sintática que deve ser feita para a criação dos mutantes Introduzir pequenas alterações semânticas através de pequenas alterações sintáticas que representam defeitos típicos Operadores dependem da linguagem alvo Ex: FORTRAN (22 operadores), C (71 operadores) X = 4 Y = 2 Z = 1 read x, y, z m := x if m < y m := y if m < z m := z print m read x, y, z m := x if m y m := y if m < z m := z print m 4 2 Aplicação de Critérios rios Estudos Teóricos e Experimentais avaliam: Custo esforço necessário para que o critério seja utilizado # de casos de teste para satisfazer o critério Strength Dificuldade de satisfação Dificuldade de satisfazer um critério, tendo satisfeito outro. Eficácia Capacidade que um critério possui de detectar erros Estratégia Incremental de Teste Custo benefício da combinação de critérios Ambiente de Teste, Depuração e Manutenção de Software Facilitam a aplicação de diferentes critérios para o teste

39 Exercícios de Fixação 1. Utilização da Técnica de Particionamento por Equivalência Programa para verificação de tipos de triângulo 2. Utilização da Análise do Valor Limite Programa para verificação de temperatura e pressão críticas em indústria química 3. Utilização do Grafo de Causa Efeito Programa para cálculo de valor de ligação em um programa de uma companhia telefônica Módulo II Conclusões As técnicas de teste atualmente existente são complementares e podem ser utilizadas em conjunto Deve ser feita uma análise de custo-benefício na empresa a respeito da aplicação de várias técnicas em conjunto. Diferente tipos de aplicações (ex: 00, aplicações web, software embarcados) possuem características específicas Isso impacta nas atividades desenvolvimento e testes Técnicas diferenciadas para desenvolvimento e testes Apoio Ferramental é essencial para a aplicação dessas técnicas como meio para reduzir o esforço e custo de sua implantação

40 Módulos III/IV Estratégias de Projeto, Execução e Controle dos Testes Módulos III/IV: Roteiro Estratégias de Teste Explorando Casos de Uso para o Teste Projetando Testes a partir de Caso de Uso Definindo e Configurando um Ambiente de Teste Executando os Testes Apoiando a Depuração das Falhas Critério de Parada dos Testes Métricas para avaliação dos testes Conclusões

41 Estratégias de Teste Baseada na implementação: Tenta-se testar cada linha de código Muito caro Muito difícil quando se tem vários caminhos Em OO, às vezes não faz sentido! Baseada na especificação: Cobrirá as imposições e restrições feitas pelos desenvolvedores a partir dos requisitos estabelecidos para o sistema Pode apoiar o desenvolvimento do software (teste de integração) Estratégias de Teste A freqüência com que cada tipo de usuário utiliza o sistema refletirá a importância relativa das características do sistema. Esta freqüência de uso pode ser representada por um perfil operacional Ter um perfil operacional qualificado representa uma estratégia eficiente para descobrir defeitos que os usuários mais encontrariam. Este perfil é difícil de se obter antes do lançamento do produto Extensões ao modelo de casos de uso podem ser feitas para se considerar este perfil operacional

42 Explorando Casos de Uso para o Teste Provêem uma representação para os requisitos funcionais de um sistema. Identificam todos os atores que disparam as funcionalidades do sistema. Ator: representa um usuário do sistema ou um estímulo de um outro sistema. Extensão ao modelo de Casos de Uso para apoiar teste Casos de uso devem considerar freqüência e criticalidade: Freqüência: define quantas vezes um determinado uso do sistema é realizado num período de tempo. mais difícil de ser obtida, porém possível de ser estimada Criticalidade: define a importância de um uso do sistema em relação ao contexto geral de utilização facilmente obtida a partir do julgamento de um especialista do domínio. Combinando-se estes dois critérios pode-se priorizar os casos de uso mais importantes e mais freqüentes.

43 Extensão ao modelo de Casos de Uso para apoiar teste A freqüência de utilização do sistema deve ser registrada para cada Ator O perfil pode ser identificado a partir da análise da responsabilidade do ator (considerações sobre o domínio). Esta característica é utilizada para ordenar os atores face a sua freqüência de utilização individual do sistema. Pode-se considerar ordenações relativas (primeiro, segundo,...), implícitas (alto, médio, baixo) ou até percentuais. Esta técnica não altera o processo básico de escolha de tipos de teste e de dados de entrada: a modificação ocorre em como sistematicamente distribuir os casos de teste pelos casos de uso com uma prioridade calculada. Extensão ao modelo de Casos de Uso para apoiar testes: Exemplo Modelagem de um sistema bancário simples onde os correntistas podem acessar suas contas através de terminais ATM. TransEletFundos RealizarDepósito Os funcionários acessarão estas contas através do sistema a ser desenvolvido. Correntista Correntistas podem realizar operações de crédito, débito e verificação de saldo. Caixa Reali zarsaque Os atores deste exemplo são correntista, caixa, gerente e sistema eletrônico de transferência de fundos. Gerente RealizarAjustes

44 Processo 1. Definir o conjunto completo de atores. 2. Definir o conjunto completo de casos de uso incluindo as associações com os atores. 3. Construir o perfil de uso para cada ator. 4. Calcular a freqüência para cada caso de uso a partir dos perfis dos atores. 5. Combinar as avaliações de freqüência e criticalidade num valor que represente a prioridade de teste. 6. Alocar casos de teste com base na prioridade de teste dos casos de uso. Template - Caso de Uso ID Caso de Uso: RealizarDepósito Nível UC: Sistema Cenário: Atores: Transf. Eletrônica de Fundos, Gerente e Correntista Pré-Condições: Conta deve estar aberta e ativa Descrição: Trigger: Ator inicia um depósito numa conta. Sistema solicita a conta destino e o valor do depósito. Ator informa o número da conta e valor do depósito. Sistema responde adicionando o valor depositado. Sistema atualiza contadores de atividade na conta. Sistema verifica se valor depositado necessita de notificação e caso necessário, gera a notificação. Requisitos Relevantes: Capacidade de aumentar valor em conta. Pós-Condições: Saldo da conta foi incrementado pelo valor depositado. Seqüências Alternativas: Se a conta não estiver ativa, ativá-la primeiro e depois Realizar o depósito. Regra de Negócio: (1) o valor do depósito deve ser maior que R$ 10,00 (2) caso o valor do depósito seja maior que R$10000,00, notificar cliente por (3) ambos os campos são obrigatórios Exceções: Número de Conta inválida, Conta inativa e Valor Inválido. Usos concorrentes: RealizarSaque Casos de Uso relacionados: RealizarSaque Freqüência: Criticalidade: Risco:

45 Perfil dos Atores Nome: Funcionário Abstrato: S/n Descrição (Papel): Tem acesso às contas bancárias Nível Conhecimento: Variado Perfil de Uso: Caso de Uso RealizarSaque RealizarDepósito RealizarAjustes Freqüência Relativa Alta Média Baixa Nome: Caixa Abstrato: N/s Descrição (Papel): Lida diretamente com os correntistas. Nível Conhecimento: Treinados, mas com níveis de experiência diversos. Perfil de Uso: Caso de Uso RealizarSaque RealizarDepósito RealizarAjustes Freqüência Relativa Média Alta Perfil dos Atores Nome: Gerente Abstrato: N/s Descrição (Papel): Supervisiona os caixas e gerencia as contas. Nível Conhecimento: Especialista. Perfil de Uso: Caso de Uso RealizarSaque RealizarDepósito RealizarAjustes Freqüência Relativa Alta Média Média Nome: Correntista Abstrato: N/s Descrição (Papel): Dono de uma conta, pode disparar atividades na mesma. Nível Conhecimento: Novato. Perfil de Uso: Caso de Uso RealizarSaque RealizarDepósito RealizarAjustes Freqüência Relativa Alta Média

46 Perfil dos Atores Nome: Transferência Eletrônica de Fundos Abstrato: N/s Descrição (Papel): Inicia atividades na conta, com algumas restrições. Nível Conhecimento: Especialista. Perfil de Uso: Caso de Uso RealizarSaque RealizarDepósito RealizarAjustes Freqüência Relativa Média Média Avaliação de Freqüência e Criticalidade Caso de Uso Freqüência Criticalidade Prioridade de Teste RealizarDepósito Média Alta Alta RealizarSaque Alta Alta Média RealizarAjustes Média Baixa Baixa

47 Avaliação de Freqüência e Criticalidade TransEletFundos Realizar Depósito de $1000 RealizarDepósito Correntista Realizar Depósito de $10000 Caixa RealizarSaque Realziar Depósito com nº de c onta inválido Gerente RealizarAjustes Projeto dos Testes a partir de Casos de Uso Um caso de uso é formado por: Atores: perfis de usuários que executam o caso de uso Pré-condições: restrições para a execução de um caso de uso Seqüência de Ações (Fluxo principal): passos ordenados para execução de um caso de uso Pós-condições: condição final a ser estabelecida ao final da execução do caso de uso Seqüências Alternativas: fluxos de ações que ocorrem paralelamente ao fluxo principal, dada uma ação específica Regras de negócio: restrições (regras) para execução de um mais passos do fluxo principal ou alternativo Exceções: estados inválidos para o sistema

48 Projeto dos Testes a partir dos casos de uso A partir desse conjunto de informações, os testes podem ser gerados, iniciando pelos casos de teste Passos a serem seguidos para geração dos testes (seguiremos o exemplo do caso de uso Realizar Depósito para o Ator CORRENTISTA, sem maiores regras): 1. Identifique os elementos presentes no caso de uso (ex. itens de menu, campos de formulários, botões, ações alternativas, etc.) Itens de Menu: Depósito e Saque Campo: conta de destino e valor do depósito. 2. Identifique a dependência entre esses elementos (ex. um campo só pode ser preenchido caso uma opção do caso de uso tenha sido previamente escolhida) Os campos conta de destino e valor do depósito só aparecem caso o item de menu Depósito tenha sido escolhido anteriormente Projeto dos Testes a partir dos casos de uso Passos a serem seguidos para geração dos testes: 3. Defina os casos de teste individuais para cada elemento do caso de uso usando uma das técnicas de teste apresentadas (ex. particionamento por equivalência, análise do valor limite, etc.) Número de Conta (usando particionamento por equivalência): T con ={( , inválida), (, inválido), ( , válido), ( ,inválido inativa)} Valor do Depósito (usando análise do valor limite): T val = {nulo(em branco), 9.99; 10; 10000; }

49 Projeto dos Testes a partir dos casos de uso Passos a serem seguidos para geração dos testes: 4. Defina os casos de teste agrupando os diferentes elementos de um caso de uso Um caso de teste será uma tupla <(conta,valor), resultado> CT01: <(,nulo), inválido> CT02: <( , 10),inválido> CT03: <( , 10000),inválido> CT04: <( , 9.99),inválido> CT05: <( , 10),válido> CT06: <( , 10000),válido> CT07: <( , ),válido gerar notificação> Projeto dos Testes a partir dos casos de uso Passos a serem seguidos para geração dos testes: 5. Represente as seqüências de ações para o caso de uso, incluindo o fluxo principal e fluxos alternativos. Além disso, deve ser considerada a ordem de preenchimento dos elementos do caso de uso (ex. elementos que dependem de outro) No diagrama a seguir, estamos considerando que o sistema não finaliza a operação, caso os dados de conta de destino e valor de depósito inválidos sejam informados

50 Correntista Sistema 1.O ator escolhe a opção REALIZAR DEPÓSITO 2. O sistema exibe a tela de depósito 3. O ator informa o valor do depósito e um telefone de contato 4. Apresenta mensagem de dados inválidos (valor < 10) ou (conta inválida) ou (conta inativa) valor >= O Sistema responde adicionando o valor depositado 6. Sistema atualiza contadores de atividade na conta 7. Sistema verifica se valor depositado necessita de notificação valor <= valor > O sistema envia notificação or 9. O sistema finaliza o depósito e retorna à tela inicial Projeto dos Testes a partir dos casos de uso Passos a serem seguidos para geração dos testes: 6. A partir do diagrama definido no passo anterior, além dos casos de teste definidos individualmente para cada elemento do caso de uso, definida o(s) procedimento(s) de teste para avaliar um cenário do caso de uso

51 Projeto dos Testes a partir dos casos de uso Os procedimentos de teste visam a definição dos passos e a ordem para executar os casos de teste definidos para os elementos do caso de uso O número de procedimentos de teste depende da quantidade de fluxos que podem ser extraídos do diagrama construído Esse número é também influenciado pela quantidade de casos de teste definidos para cada evento que compõe o grafo Cada evento está associado a um ou mais casos de teste Projeto dos Testes a partir dos casos de uso Definição dos procedimentos de teste: 7. Extraia os diferentes caminhos do diagrama, considerando que todas as ações devam ser executadas ao menos uma vez. A decisão de qual algoritmo de grafo de programa usar depende de quem esta projetando os testes. Ex. Caminhos diferentes em caso de ciclos podem ser extraídos ou não, além de outros problemas conhecidos de grafos. No caso do nosso exemplo, dois caminhos foram extraídos: CAMINHO 1: 1, 2, 3, 4, 2, 3, 5, 6, 7, 9 CAMINHO 2: 1, 2, 3, 4, 2, 3, 5, 6, 7, 8, 9

52 Projeto dos Testes a partir dos casos de uso Definição dos procedimentos de teste: 7. Por fim, gere procedimentos de teste que executem todos os casos de teste definidos no passo, combinando os casos de teste de diferentes elementos Procedimentos: PT01: Teste de valores inválidos (CT01, CT02, CT03, CT04) + Teste de valor de depósito = 10 (CT05 limite inferior) CAMINHO 1 PT02: Teste de valor de depósito = (CT06 limite superior sem a geração de notificação) CAMINHO 1 PT03: Teste de valor de depósito = (CT07 limite superior com a geração de notificação) CAMINHO 2 Exemplo de Procedimento de Teste Procedimento de Teste 01: Passo 1. Ator inicia um depósito numa conta. 2. Sistema solicita o valor do depósito e um telefone para contato. Caso de Teste 3. Ator informa a conta destino e o valor do depósito. CT01 4. Sistema apresenta uma mensagem de dados inválidos CT01 5. Ator informa a conta destino e o valor do depósito. CT02 6. Sistema apresenta uma mensagem de dados inválidos CT02 7. Ator informa a conta destino e o valor do depósito. CT03 8. Sistema apresenta uma mensagem de valor de depósito inválido CT03 9. Ator informa a conta destino e o valor do depósito. CT Sistema apresenta uma mensagem de valor de depósito inválido CT Ator informa a conta destino e o valor do depósito. CT Sistema atualiza contadores de atividade na conta. CT Sistema verifica se valor depositado necessita de notificação. e caso necessário, gera a notificação CT O sistema finaliza o caso de uso CT05

53 Priorização de Procedimentos de Teste Devemos supor que existam casos e procedimentos de teste para os outros casos de uso. Sendo assim, em que ordem os procedimentos de teste devem ser executados? Normalmente, aplicações possuem um fluxo de atividades definido Esse fluxo pode ser seguido durante a execução dos testes Assim, resultados da execução de um procedimento de teste pode ser aproveitado em procedimentos seguintes Ex: primeiramente executar um cadastro, e depois uma alteração (ou exclusão do item que foi incluído, ou sua consulta) Priorização de Procedimentos de Teste No exemplo do sistema bancário, podemos supor a existência de casos e procedimentos de teste para o caso de uso LOGAR NO SISTEMA Assim, todos os casos de teste para REALIZAR DEPÓSITO dependem dos casos de teste para LOGAR NO SISTEMA, pois isso é uma pré-condição do caso de uso Assim, procedimentos de teste para REALIZAR DEPÓSITOS devem ser executados após os procedimentos de teste para LOGAR NO SISTEMA Uma outra opção seria unir os procedimentos de teste para o caso de uso LOGAR NO SISTEMA com os procedimentos de teste para REALIZAR DEPÓSITO

54 Projeto dos Testes a partir dos casos de uso Note que nesses exemplos, casos e procedimentos de teste foram apenas citados, não especificados! A especificação consiste na documentação dos casos e procedimentos de acordo com o que foi apresentado no módulo I Especificar as dependências entre os casos de teste, Especificar as restrições do procedimento de teste, Requisitos computacionais para execução,... Exemplos que não foram especificados para o sistema bancário: Restrição: Para todos os procedimentos de teste definidos, o correntista já deve estar autenticado no sistema) Comportamento a ser observado: atualização do contador de atividade da conta Definindo e Configurando um Ambiente de Teste Antes do início da execução dos testes, deve ocorrer a configuração do ambiente em que os testes serão executados Isso inclui: Espaço físico para execução dos testes Testes podem requerer a alocação de um espaço específico Equipamentos Testes podem requerer a alocação de um equipamento diferenciado (ex. servidor, um simulador, etc.) Banco de dados e servidores Testes requerem uma base de dados independente da base de desenvolvimento para evitar dados sem integridade (normais durante o desenvolvimento), garantindo que esses dados não interfiram nos resultados dos testes Ferramentas A execução dos testes pode necessitar de ferramentas específicas para os testes, como simuladores ou capture-replay Material de apoio, treinamento Pode haver a necessidade de materiais adicionais de apoio ou treinamentos específicos para a execução dos testes em um projeto. Ex. treinamento sobre o uso de um simulador de vôo

55 Definindo e Configurando um Ambiente de Teste O ambiente de teste deve ser configurado de acordo com o nível de teste e com o tipo de software a ser realizado Nível de teste (exemplos): Um ambiente para teste de stress deve prover uma simulação em que os recursos da infra-estrutura são sobrecarregados ou múltiplos acessos devem se providos Teste de segurança deve tentar revelar vulnerabilidades da infraestrutura onde o sistema ficará disponível Teste alfa deve prever uma infra-estrutura similar àquela em que o sistema irá funcionar após a entrega... Tipo de software (exemplo): Um ambiente de teste para sistema embarcado deve prover simuladores específicos para o hardware Alguns tipos de software requerem habilidades para execução dos testes. Ex. um simulador de vôo... Executando os Testes Testador: Seguir o que foi definido durante o planejamento Registrar todas as atividades que ocorrem Normalmente, não conseguimos prever as falhas, e podemos perder a seqüência de eventos que a ocasionou Tentar explicar com detalhes o que levou à ocorrência da falha, utilizando telas capturas Analisar a possibilidade de executar testes em paralelo Alguns procedimentos de teste podem ser executados em paralelo. Ex. testes para itens diferentes

56 Controlando os Testes Gerente de Teste: Garantir que os testes planejados estejam sendo executados e verificar os resultados dos testes Analisar o grau de impacto dos incidentes relatados Repassar os incidentes de teste à equipe de desenvolvimento Utilizar ferramentas de bug tracking (ex. BugZilla) Facilita a documentação e possibilita o acompanhamento de um incidente de teste até a sua correção pelos desenvolvedores Definir um momento adequado para finalizar os testes Chega um ponto onde os custos de continuar os testes são maiores que os benefícios dos testes Apoiando a Depuração das Falhas (Rastreabilidade) Incidente de Teste (Falha) Observado através de um Caso/Procedimento de Teste Associado a um Que possui Que deverá ser corrigido Item de Teste Defeito

57 Apoiando a Depuração das Falhas (Rastreabilidade) Criar níveis na matriz de rastreabilidade para casos e procedimentos de teste Link dos casos e procedimentos de teste com os itens do projeto (classes componentes casos de uso requisitos) A matriz deve ser atualizada constantemente em caso de mudanças nos itens do projeto Facilita a evolução dos testes, e conseqüentemente testes de regressão Indicação explícita dos casos ou procedimentos de teste a serem atualizados ou que não fazem mais parte dos testes de um software Métricas para Avaliação dos Testes Objetivo: Caracterizar estatisticamente as atividades de teste de um projeto Medir, avaliar e sugerir melhorias nas atividades de teste ou de desenvolvimento para projetos futuros Permitir realização de estudos a respeito de decisões tomadas ao longo dos testes Não meça só para colecionar medições! Meça para identificar ou resolver um problema.