Programação e Desenvolvimento Dirigidor por Testes
  • Programação e Desenvolvimento Dirigidor por Testes em Python
  • Autores e Agradecimentos
  • Uso do Livro
  • Contribua com o Livro
  • Licença
  • Organização do Livro
  • 1 Introdução
    • 1.1 Considerações Iniciais
    • 1.2 Configuração Inicial do Ambiente
    • 1.3 TDD Básico
      • 1.3.1 Exemplo Simples
    • 1.4 Considerações Finais
  • 2 TESTE DE SOFTWARE
    • 2.1 Considerações Iniciais
    • 2.2 Terminologia e Conceitos Básicos
    • 2.3 Fases de Teste
    • 2.4 Técnicas e Critérios de Teste
    • 2.5 Considerações Finais
  • 3 Desenvolvimento Dirigido por Teste
    • 3.1 Configuração do Ambiente
    • 3.2 Verificando o Ambiente com TDD
    • 3.3 Controle de Versão do Projeto
    • 3.4 Teste Funcional com UnitTest
    • 3.5 Teste de Unidade e a Evolução do Sistema
      • 3.5.1 Teste de Unidade de uma View
    • 3.6 Evoluindo o Teste Funcional
    • 3.7 Revisando o Processo do TDD
  • 4 TDD E BANCO DE DADOS
    • 4.1 Envio e Processamento de Requisição POST
    • 4.2 Banco de Dados no Django
  • 5 MELHORANDO E ORGANIZANDO OS CONJUNTOS DE TESTE
    • 5.1 Isolamento dos Testes Funcionais
    • 5.2 Esperas Implícitas, Explícitas e Time Sleeps
  • 6 ATACANDO O MAIOR DESAFIO DE FORMA INCREMANTAL
    • 6.1 Separando URL no Estilo REST
    • 6.2 Iterando para um Novo Design da Aplicação
    • 6.3 Refatorar Casos de Teste
    • 6.4 Separando Templates
    • 6.5 URL para Nova Lista
    • 6.6 Alterando Modelos
    • 6.7 URL Próprio para Cada Lista
Powered by GitBook
On this page

Was this helpful?

  1. 2 TESTE DE SOFTWARE

2.2 Terminologia e Conceitos Básicos

Previous2.1 Considerações IniciaisNext2.3 Fases de Teste

Last updated 11 months ago

Was this helpful?

A IEEE realiza vários esforços de padronização, entre eles a padronização da terminologia utilizada no contexto de Engenharia de Software. O padrão diferencia os termos: defeito (fault) – passo, processo ou definição de dados incorreto, como por exemplo, uma instrução ou comando incorreto; engano (mistake) – ação humana que produz um resultado incorreto, com por exemplo, uma ação incorreta tomada pelo programador; erro (error) – diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado intermediário incorreto ou resultado inesperado na execução do programa constitui um erro; e falha (failure) – produção de uma saída incorreta com relação à especificação.

A figura abaixo ilustra o relacionamento entre os termos, sendo o defeito e o erro considerados a causa e a falha, a consequência.

De uma forma geral, os defeitos são classificados em: defeitos computacionais – o defeito provoca uma computação incorreta mas o caminho executado (sequências de comandos) é igual ao caminho esperado; e defeitos de domínio – o caminho efetivamente executado é diferente do caminho esperado, ou seja, um caminho incorreto é selecionado.

Diz-se que um programa PPPcom domínio de entrada DDD é correto com respeito a uma especificação SSSse S(d)=P∗(d)S(d) = P^*(d)S(d)=P∗(d)para qualquer item de dado d∈Dd \in Dd∈D, ou seja, se o comportamento do programa está de acordo com o comportamento esperado para todos os dados de entrada. Dados dois programas P1P_1P1​e P2P_2P2​ , se P1∗(d)=P2∗(d)P^*_1(d) = P^*_2(d)P1∗​(d)=P2∗​(d), para qualquer d∈Dd \in Dd∈D, diz-se que P1P_1P1​e P2P_2P2​ são equivalentes.

No teste de software, pressupõe-se a existência de um oráculo – o testador ou algum outro mecanismo – que possa determinar, para qualquer item de dado d∈Dd \in Dd∈D , se S(d)=P∗(d)S(d) = P^*(d)S(d)=P∗(d), dentro de limites de tempo e esforços razoáveis. Um oráculo simplesmente decide se os valores de saída apresentados por PPP são corretos em relação à especificação SSS.

Sabe-se que o teste exaustivo é impraticável, ou seja, testar para todos os elementos possíveis do domínio de entrada é, em geral, caro e demanda muito mais tempo do que o disponível. Ainda, deve-se salientar que não existe um procedimento de teste de propósito geral que possa ser usado para provar a correção de um programa. Apesar de não ser possível, por meio dos testes, provar que um programa está correto, os testes, se conduzidos sistemática e criteriosamente, contribuem para aumentar a confiança de que o software desempenha as funções especificadas e evidenciar algumas características mínimas do ponto de vista da qualidade do produto.

Assim, duas questões são chaves na atividade de teste: "Como os dados de teste devem ser selecionados?" e "Como decidir se um programa PPP foi suficientemente testado?". Critérios para selecionar e avaliar conjuntos de casos de teste são fundamentais para o sucesso da atividade de teste. Tais critérios devem fornecer indicação de quais casos de teste devem ser utilizados de forma a aumentar as chances de fazer o software falhar, evidenciando a presença de defeitos no mesmo, ou quando falhas não ocorrerem, estabelecer um nível elevado de confiança na correção do programa.

Um caso de teste consiste de um par ordenado (d,S(d))(d, S(d))(d,S(d)), no qual d∈Dd \in Dd∈D é denominado de dado de teste, e corresponde à entrada fornecida ao programa, e S(d)S(d)S(d)é a respectiva saída esperada conforme a especificação.

Dados um programa PPPe um conjunto de teste TTT, definem-se:

  • Critério de Adequação de Casos de Teste: predicado para avaliar TTT no teste de PPP; e

  • Método de Seleção de Casos de Teste: procedimento para escolher casos de teste para o teste de PPP.

Em outras palavras, o papel de um critério de teste é o de gerar os chamados requisitos de testes. Tais requisitos podem ser utilizados para avaliar a adequação (critério de adequação) de um conjunto de teste já existente, ou os requisitos são utilizados para guiar a geração de casos de teste (método de seleção).

A atividade de teste é permeada por uma série de limitações (). Em geral, os seguintes problemas são indecidíveis: dados dois programas, se eles são equivalentes; dados duas sequências de comandos (caminhos) de um programa, ou de programas diferentes, se eles computam a mesma função; e dado um caminho se ele é executável ou não, ou seja, se existe um dado de entrada que leva à execução desse caminho. Outra limitação fundamental é a correção coincidente – o programa pode apresentar, coincidentemente, um resultado correto para um item particular de um dado d ∈ D, ou seja, um particular item de dado ser executado, satisfazer a um requisito de teste e não faz o software falhar.

Delamaro et al. 2016
ISO/IEC/IEEE 24765-2017
Relação entre os termos