Pergunta

eu fui ensinado que um teste de regressão foi um pequeno (apenas o suficiente para provar que você não quebrar nada com a introdução de uma mudança ou novos módulos) amostra dos testes globais. No entanto, este artigo por Ron Morrison e Grady Booch me faz pensar de forma diferente:

A estratégia desejada seria trazer cada unidade em um de cada vez, realizar um extenso teste de regressão, corrigir os defeitos e, em seguida, avançar para a próxima unidade.

O mesmo documento também diz:

Assim que um pequeno número de unidades são adicionadas, uma versão de teste é gerado e "fumaça testado", onde um pequeno número de testes são executados para ganhar confiança de que o produto integrado irá funcionar como esperado. A intenção não é nem para testar exaustivamente a nova unidade (s) nem completamente testes de regressão do sistema global.

Ao descrever testes de fumaça, os autores dizem que isso:

Também é importante que o Smoke Teste executar uma verificação rápida de todo o sistema, e não apenas o novo componente (s).

Eu nunca vi "extensa" e "teste de regressão" usados ??juntos nem um teste de regressão descrita como "completamente de testes de regressão do sistema global". testes de regressão é suposto ser o mais leve e mais rápido possível. E a definição de teste de fumaça é o que eu aprendi um teste de regressão foi.

Eu entendi mal o que me foi ensinado? Me foi ensinado incorretamente? Ou existem múltiplas interpretações do "teste de regressão"?

Foi útil?

Solução

Existem várias interpretações. Se você está se fixar apenas um bug que afeta uma pequena parte do seu sistema, então, testes de regressão só poderia incluir um pequeno conjunto de testes que exercem a classe ou pacote em questão. Se você está a fixação de um bug ou adicionar um recurso que tem maior alcance, em seguida, seus testes de regressão devem ter escopo mais amplo também.

O "se ele poderia quebrar, testá-lo" regra de ouro se aplica aqui. Se uma mudança na Foo poderia afetar Bar, em seguida, executar as regressões para ambos.

testes de regressão apenas verificar para ver se uma mudança causou um teste passou previamente a falhar. Eles podem ser executados em qualquer nível (unidade, integração, sistema). referência.

Outras dicas

Eu sempre assumiu testes de regressão para significar qualquer teste cujo objectivo era o de garantir que a funcionalidade existente não é quebrada por novas mudanças. Isso não implica qualquer restrição sobre o tamanho do conjunto de teste.

A regressão é geralmente usado para se referir a todo o conjunto de testes. É a última coisa QA faz antes de uma liberação. Ele é usado para mostrar que tudo o que costumava trabalhar ainda funciona, na medida em que isso é possível para mostrar. Na minha experiência, é geralmente um conjunto de todo o sistema de testes, independentemente de quão pequena a mudança foi (embora pequenas mudanças podem não desencadear um teste de regressão).

Onde eu trabalho, testes de regressão são padronizados para cada aplicação no final de cada lançamento. Eles são destinados a testar todas as funcionalidades, mas eles não são projetados para capturar erros sutis. Então se você tem um formulário que tem vários tipos de validação feita sobre ele, por exemplo, uma suite de regressão para essa forma seria para confirmar que cada tipo de validação é feito (nível de campo e nível de forma) e que a informação correta pode ser submetido . Ele não foi projetado para cobrir todos os casos (ou seja, o que se eu deixar de campo Um espaço em branco? Como cerca de campo B? Ele só irá testar um deles e assumir a outros trabalhos).

No entanto, no projeto atual que estou trabalhando, os testes de regressão são muito mais completa, e temos notado uma redução no número de defeitos sendo levantadas durante os testes. Aqueles dois não estão necessariamente relacionadas, mas fazemos aviso-lo bastante consistente.

meu entendimento do termo 'teste de regressão' é:

  • testes de unidade são gravados em recursos de teste quando o sistema é criado
  • quando erros são descobertos, mais testes unitários são escritos para reproduzir o erro e verificar que ele foi corrigido
  • um teste de regressão é executado todo o conjunto de testes provar que tudo ainda funciona incluindo que há erros antigos reapareceram [isto é para provar que o código não foi "regrediu"]

Na prática, o melhor é sempre executar todos os testes de unidade existentes quando são feitas alterações. a única vez que eu iria se preocupar com um subconjunto de testes é quando a suíte de teste de unidade completa leva "muito longo" para executar [onde "demasiado longo" é bastante subjetiva]

Comece com o que você está tentando realizar. Em seguida, fazer o que você precisa fazer para atingir esse objetivo. E então usar bingo buzzword para atribuir uma palavra para o que você realmente faz. Assim como todos os outros :-) Precisão não é tão importante.

... teste de regressão foi um pequeno (apenas o suficiente para provar que você não quebrar nada com a introdução de uma mudança ou novos módulos) amostra dos testes gerais

Se uma pequena amostra de testes é suficiente para provar que o sistema funciona, por que o resto dos testes ainda existe? E se você pensa que sabe que a alteração só afetou um subconjunto de funcionalidade, então por que você precisa testar qualquer coisa depois de fazer a mudança? Os seres humanos são falíveis, ninguém sabe realmente se mudando algo quebrar outra coisa. IMO, se seus testes são automatizados, re-executar todos eles. E se eles não são automatizadas, automatizá-las. Nesse meio tempo, re-run tudo o que é automatizado.

De uma maneira geral, um subconjunto dos testes apresentam para a nova funcionalidade introduzida na versão X de um produto torna-se a base dos testes de regressão para a versão x + 1, x + 2, e assim por diante. Com o tempo, você pode reduzir o tempo que os testes de funcionalidade / regressão de recursos estáveis, que não sofreram de regressões. Se um recurso sofre de lotes de regressões, então ele pode ser benéfico para aumentar a ênfase sobre o recurso.

Eu acho que o artigo referente a meios 'extenso de testes de regressão' executar um extenso conjunto de testes de regressão (individualmente simples).

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top