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.3 Fases de Teste

Previous2.2 Terminologia e Conceitos BásicosNext2.4 Técnicas e Critérios de Teste

Last updated 4 years ago

Was this helpful?

O teste de produtos de software envolve basicamente quatro etapas: planejamento de testes, projeto de casos de teste, execução e avaliação dos resultados dos testes (). Essas atividades devem ser desenvolvidas ao longo do próprio processo de desenvolvimento de software, e em geral, concretizam-se em três fases de teste: de unidade, de integração e de sistema.

Um modelo clássico, denominado Modelo-V, alinha as atividades de desenvolvimento com as atividades de teste.

O teste de unidade concentra esforços na menor unidade do projeto de software, ou seja, procura identificar defeitos de lógica e de implementação em cada módulo do software, separadamente.

O teste de integração é uma atividade sistemática aplicada durante a integração da estrutura do programa visando a descobrir erros associados às interfaces entre os módulos; o objetivo é, a partir dos módulos testados no nível de unidade, construir a estrutura de programa que foi determinada pelo projeto.

O teste de sistema, realizado após a integração do sistema, visa a identificar erros de funções e características de desempenho que não estejam de acordo com a especificação.

O teste de aceitação é aquele realizado pelo usuário para se assegurar de que o produto desenvolvido atende suas necessidades.

Nos últimos anos, muito em decorrência da adoção de métodos ágeis ou de parte das práticas ágeis, houve uma demanda por automatização de teste de software. Entretanto, a grande maioria das empresas, quando iniciam o processo de automatização, em geral, o fazem para executar o sistema como um todo, ou seja, no nível de sistema. O problema é que testes automatizados no nível de sistema tendem a apresentar mais vantagens do que desvantagens pois demandam mais código para a automatização, costumam executar lentamente, e precisam de manutenção sempre que ocorre mudanças na interface do produto.

De toda forma, o que não pode deixar de ser feito é não se testar. O TDD prega que os testes devem ser construídos antes de se construir a aplicação e, desse modo, os testes estarão garantidos para assegurar a qualidade da aplicação desde o início e funcionam como um importante instrumento para se evitar que defeitos ocasionais quebrem a aplicação sem serem descobertos rapidamente. Em outras palavras, o TDD oferece um feedback instantâneo a cada mudança implementada.

O ideal seria que a automatização respeitasse a pirâmide de teste, conforme descrita por . Um exemplo da Pirâmide de Teste, inspirada no artigo citado é dado abaixo.

A pirâmide sugere que a maior quantidade de testes automatizados deve ser de testes unitários, seguidos de uma porção menos de testes de integração e uma porção menor ainda de testes de sistemas. Segundo , recomendação geral é que esses três testes sejam implementados na seguinte proporção: 70% como testes de unidades; 20% como testes de integração e 10% como testes de sistema.

Vocke (2018)
Whittaker et al. (2012)
Delamaro et al. 2016
Modelo V
Ilustração sobre as Fases de Teste
Pirâmide de Teste: proporção de testes automatizados sugerida.