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

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

1. Motivação

   • Estudos mostram
     • Praticamente todos os “módulos” de um software possuem defeitos durante o desenvolvimento Após a liberação 40% estão livres de defeitos
     • É praticamente impossível liberar software sem defeito
     • Interesse crescente na atividade de teste principalmente pela crescente demanda por software de alta qualidade
     • Grupos de pesquisa em teste de software proliferam no mundo
     • Vagas na indústria para engenheiros de teste se multiplicam

2. Verificação vs Validação

   • Verificação
     • estamos fazendo o sistema corretamente?
       • De acordo com os requisitos e especificações
   • Validação
     • estamos fazendo o sistema correto?
       • Aquele que os clientes querem
       • Testes de aceitação com os usuários

3. Teste de Software

   • Verifica se um programa apresenta um resultado esperado, ao ser executado com alguns casos de teste
   • Podem ser:
     • Manuais
     • Automatizados
   • Verdade - Testes podem mostrar a presença de bugs, mas não a ausência de bugs em um sistema
   • Verdade - Testes podem provar que um programa está incorreto, mas eles não provam que ele está correto.
   • Falso - Todo teste deve ter obrigatoriamente um único comando assert.
   • Verdade - Teste caixa-preta é também chamado de funcional; teste caixa-branca é chamado de não-funcional.
   • Falso - As principais etapas da atividade de teste são: planejamento, projeto de casos de teste, execução e análise.

4. O que é Teste de Software?

   • Forma de procurar garantir que o produto de software atende aos requisitos que foram definidos para ele.
     • Correção, desempenho, segurança etc
   • Não é a única forma, mas talvez a mais importante.
   • De acordo com IEEE Standard Glossary 610.12-1990 (R 2002).
     • O processo de executar um sistema ou componente sob condições específicas, observando ou registrando os resultados e fazendo uma avaliação de algum aspecto do sistema ou componente.

5. Desafios do Teste

   • Alguém já testou algum produto de software? Quais foram os maiores desafios?
   • Alguns problemas comuns são:
     • Não há tempo para o teste exaustivo
     • Muitas combinações de entrada para serem exercitadas. Dificuldade em determinar os resultados esperados para cada caso de teste.
     • Requisitos do software inexistentes ou que mudam rapidamente. Não há tempo suficiente para o teste.
     • Não há treinamento no processo de teste. Não há ferramenta de apoio
     • Gerentes que desconhecem teste ou que não se preocupam com qualidade

6. Partes de um Caso de Teste

   • Um caso de teste bem projetado é dividido em três partes:
     • Entradas (inputs);
       • Geralmente identificadas como dados fornecidos via teclado para o programa executar
       • Entretanto, os dados de entrada podem ser fornecidos por outros meios, tais como:
         • Dados oriundos de outro sistema que servem de entrada para o programa em teste;
         • Dados fornecidos por outro dispositivo; Dados lidos de arquivos ou banco de dados
         • O estado do sistema quando os dados são recebidos; O ambiente no qual o programa está executando
     • Saídas Esperadas (outputs);
       • As saídas também podem ser produzidas de diferentes formas.
       • A mais comum é aquela apresentada na tela do computador
       • Além dessa, as saídas podem ser enviadas para:
         • Outro sistema interagindo com o programa em teste; Dados enviados para um dispositivo externo;
         • Dados escritos em arquivos ou banco de dados; O estado do sistema ou o ambiente de execução podem ser alterados durante a execução do Programa
     • Ordem de execução (order of execution).
       • Existem dois estilos de projeto de casos de teste relacionados com a ordem de execução:
         • Casos de teste em cascata
           • quando os casos de teste devem ser executados um após o outro, em uma ordem específica. O estado do sistema deixado pelo primeiro caso de teste é reaproveitado pelo segundo e assim sucessivamente.
           • Por exemplo, considere o teste de uma base de dados:
             • criar um registro ler um registro
             • atualizar um registro
             • ler um registro
             • apagar um registro
             • ler o registro apagado
           • Vantagem
             • casos de testes tendem a ser pequenos e simples. Fáceis de serem projetados, criados e mantidos
           • Desvantagem
             • se um caso de teste falhar os casos de teste subsequentes também podem falhar.
         • Casos de teste independentes.
           • Cada caso de teste é inteiramente autocontido
           • Vantagem
             • casos de teste podem ser executados em qualquer ordem
           • Desvantagem
             • casos de teste tendem a ser grandes e complexos, mais difíceis de serem projetados, criados e mantidos
     • Oráculo
       • Todas as formas de entrada e saída são relevantes
       • Durante o projeto de um caso de teste, determinar correção da saída esperada é função do oráculo (oracle).
       • Oráculo corresponde a um mecanismo (programa, processo ou dados) que indica ao projetista de casos de testes a saída obtida para um caso de teste é aceitável ou não
       • Beizer (1990) lista os principais tipos de oráculos:
         • Conjunto de Teste Padrão
           • execute o programa com um conjunto de teste padrão que tenha sido previamente criado e validado. Utilizado na validação de compiladores, navegadores Web e processadores de SQL.
         • Conjunto de Teste de Regressão
           • execute o programa e compare a saída obtida com a saída produzida por uma versão mais antiga do programa.
         • Validação de Dados
           • execute o programa e compare a saída obtida com uma saída padrão determinada por uma tabela, fórmula ou outra definição aceitável de saída válida.
         • Programa existente
           • execute o programa em teste e o programa existente com o mesmo caso de teste e compare as saídas.
             • Semelhante ao teste de regressão
       • Verdade - Oráculo corresponde a um mecanismo (programa, processo ou dados) que indica ao projetista de casos de testes a saída obtida para um caso de teste é aceitável ou não

7. Tipos de Teste

   • Diferentes tipos de testes podem ser utilizados para verificar se um programa se comporta como o especificado.
   • Basicamente, os testes podem ser classificados em:
     • Teste funcional
       • os testes são baseados exclusivamente na especificação de requisitos do programa. Nenhum conhecimento de como o programa está implementado é requerido.
       • Verdade - Na técnica de teste funcional os requisitos de teste são derivados da especificação do produto de software.
     • Teste estrutural
       • os testes são baseados na estrutura interna do programa, ou seja, na implementação dele.
       • Falso - Na técnica de teste estrutural a estrutura interna do programa não é conhecida
     • Teste baseado em defeitos
       • os testes são baseados em informações histórica sobre defeitos cometidos frequentemente durante o processo de desenvolvimento de software.
   • Esses tipos de teste correspondem às chamadas técnicas de teste
   • A técnica de teste é definida pelo tipo de informação utilizada para realizar o teste.
   • Cada técnica de teste possui um conjunto de critérios de teste.
   • Os critérios sistematizam a forma como requisitos de teste devem ser produzidos a partir da fonte de informação disponível (especificação de requisitos, código fonte, histórico de defeitos, dentre outras).
   • Os requisitos de teste são utilizados para: Gerar casos de teste.
     • Avaliar a qualidade de um conjunto de teste existente

8. Fases de teste

   • A atividade de teste também é dividida em fases, conforme outras atividades de Engenharia de Software.
   • Objetivo é reduzir a complexidade dos testes. Conceito de “dividir e conquistar”.
   • Começar testar a menor unidade executável até atingir o programa como um todo
   • Principais Fases de Teste
     • Teste de Unidade
       • Objetivo é identificar erros de lógica e de programação na menor unidade de programação
       • Diferentes linguagens possuem unidades diferentes
         • Pascal e C possuem procedimentos ou funções
         • Java e C++ possuem métodos (ou classes?).
         • Basic e COBOL (o que seriam unidades?).
       • Como testar uma unidade que depende de outra para ser executada?
       • Como testar uma unidade que precisa receber dados de outra unidade para ser executada?
       • Driver e Stub
         • Para auxiliar no teste de unidade, em geral, são necessários drivers e stubs.
         • O driver é responsável por fornecer para uma dada unidade os dados necessários para ela ser executada e, posteriormente, apresentar os resultados ao testador.
         • O stub serve para simular o comportamento de uma unidade que ainda não foi desenvolvida, mas da qual a unidade em teste depende.
       • Verdade - Na fase de testes de unidade, o objetivo é explorar a menor unidade de projeto, procurando identificar erros de lógica e de implementação de cada módulo; na fase de teste de integração, o objetivo é descobrir erros associados às interfaces entre os módulos quando esses são integrados, para se construir a estrutura do software. (ENADE 2005)
     • Teste de Integração
       • Objetivo é verificar se as unidades testadas individualmente se comunicam como desejado
       • Por que testar a integração entre unidades se as mesmas, em isolado, funcionam corretamente?
       • Dados podem se perder na interface das unidades.
       • Variáveis globais podem sofrer alterações indesejadas
       • Verdade - O framework JUnit (e similares) também pode ser usado para testes de integração
       • Verdade - O framework JUnit (e similares) pode ser usado para testes de unidade
     • Teste de Sistema
       • Objetivo é verificar se o programa em si interage corretamente com o sistema para o qual foi projetado. Isso inclui, por exemplo, o SO, banco de dados, hardware, manual do usuário, treinamento etc
       • Corresponde a um teste de integração de mais alto nível. Inclui teste de funcionalidade, usabilidade, segurança, confiabilidade, disponibilidade, performance, backup/restauração, portabilidade, entre outros (Norma ISO-IEC-9126 para mais informações ISO/IEC (1991)).
       • Testam uma funcionalidade ou serviço (do seu sistema)
       • Incluindo classes e serviços externos (BD, por exemplo)
     • Falso - A pirâmide de testes tem três níveis: integração fica no topo e testes de unidade ficam na base.
     • Verdade - A pirâmide de testes tem três níveis: teste de sistemas fica no topo e testes de unidade ficam na base

9. Teste de Aceitação

   • Objetivo é verificar se o programa desenvolvido atende as exigências do usuário
   • Verdade - Testes de aceitação são uma atividade de validação; testes de unidade são atividades de verificação de software

10. Teste de Regressão

    • Mesmo após liberado o software precisa ser testado
    • A cada manutenção é preciso verificar se o software mantém suas características
    • Se nenhum efeito colateral foi introduzido
    • Técnicas de teste de regressão reutilizam subconjuntos do conjunto de teste existente

11. Algumas definições

    • Validação:
      • o processo de avaliar o software, ao final do seu desenvolvimento com o objetivo de garantir conformidade com o seu uso esperado.
      • Requer conhecimento do domínio para o qual o software foi desenvolvido
    • Verificação:
      • o processo de determinar se os produtos de uma determinada fase de desenvolvimento do software estão de acordo com os requisitos estabelecidos nas fases anteriores.
      • Atividade mais técnica, que usa conhecimento sobre artefatos particulares, requisitos e especificações
    • Teste:
      • Avaliação do software por meio da observação de sua execução

12. Defeito, Erro e Falha

    • Defeito:
      • uma incorreção estática no código
      • Verdade - Quanto mais tarde um defeito é revelado, maior será o custo para sua correção
      • Falso - Defeitos são identificados apenas nos níveis de teste de unidade e integração
    • Erro:
      • um estado interno incorreto, que é consequência da execução de um defeito.
    • Falha:
      • comportamento externo incorreto, com respeito aos requisitos ou qualquer outra descrição do comportamento esperado
      • Para uma falha ocorrer (RIP)
        • O ponto do programa que contém um defeito deve ser executado (alcançabilidade).
        • Após a execução deste ponto, o estado da execução deve ser incorreto (infecção).
        • O estado infectado deve se propagar de modo a produzir uma saída incorreta (propagação).
        • RIP (Reachability, Infection, Propagation).
      • Verdade - Toda falha é causada por um bug (ou defeito); mas nem todo bug causa uma falha
      • Falso - Uma falha é um passo incorreto durante a codificação.

13. Automatização dos testes

    • A atividade de teste é cara e consome muito tempo. Automatizar
    • significa:
      • Diminuir custos
      • Diminuir erros
      • Facilitar teste de regressão
    • Atividades intelectuais × atividades braçais
    • Suporte a técnicas de teste
    • Geração de dados de teste
    • Oráculos

14. Desenvolvimento Dirigido por Testes (TDD)

    • Uma das práticas de programação propostas por XP
    • Ideia simples: escrever o teste T antes da classe C
    • Benefícios
      • Evita que os devs esqueçam de escrever os testes
      • Incentiva a escrita de código com testabilidade
      • Melhora o design do código, pois o dev passa a ser o primeiro cliente do seu código
      • Cobertura pode chegar a 90%
    • Ciclo TDD
      • Testes Falhandos
      • Testes Passando
      • Refatoração
      • Verdade - O ciclo TDD é composto por: (1) testes falhando, (2) testes passando, (3) Refatoração

15. Cobertura de Testes

    • Cobertura de testes = (número de comandos executados pelos testes) / (total de comandos do programa)
    • Qual a cobertura de testes ideal?
      • Varia de projeto para projeto
      • Mas não precisa ser 100%
      • Pelo menos 60%, segundo alguns autores
      • Falso - A cobertura ideal a ser atingida pelos testes é sempre de 100% para qualquer projeto de software.