O que são testes de unidade, testes de integração, testes de fumaça e testes de regressão?


732

O que são testes de unidade, testes de integração, testes de fumaça e testes de regressão? Quais são as diferenças entre eles e quais ferramentas posso usar para cada um deles?

Por exemplo, eu uso JUnit e NUnit para teste de unidade e teste de integração . Existem ferramentas para os dois últimos testes de fumaça ou regressão ?



1
Outros já responderam bem, mas eu gostaria de acrescentar que, pessoalmente, acho que o teste de fumaça e o teste de regressão são redundantes. Eles fazem a mesma coisa: teste para garantir que as alterações no sistema não quebrem nada.
21909 Randolpho

15
Eu acho que eles são bem diferentes dos testes de regressão. Eu acho que eles são testes rápidos deliberadamente "leves" que são executados no início para economizar tempo, porque se algum deles falhar, você sabe que não vale a pena se preocupar com nenhum teste adicional. Por exemplo, o cliente pode se conectar ao banco de dados, está instalado .net, está instalada a versão correta ... Você também pode ter uma pré-implantação (estamos atualizando da v1 para a v1.1, verifique se a v1 está instalada) e pós- testes de fumaça de implantação.
AndyM

Os testes de fumaça são como AndyM descreveu. Mas eles também são um tipo de teste de regressão.
55568 Krypton McNamara #

Respostas:


1044
  • Teste de unidade : especifique e teste um ponto do contrato do método único de uma classe. Isso deve ter um escopo muito estreito e bem definido. Dependências e interações complexas com o mundo exterior são stubbed ou ridicularizadas .

  • Teste de integração : Teste a interoperação correta de vários subsistemas. Existe todo o espectro, desde testar a integração entre duas classes até testar a integração com o ambiente de produção.

  • Teste de fumaça (também conhecido como verificação de integridade ) : um teste de integração simples, onde apenas verificamos que, quando o sistema em teste é chamado, ele retorna normalmente e não explode.

    • O teste de fumaça é uma analogia com a eletrônica, onde o primeiro teste ocorre ao ligar um circuito (se ele fuma, é ruim!) ...
    • ... e, aparentemente , com encanamento , onde um sistema de tubos é literalmente cheio de fumaça e depois verificado visualmente. Se alguma coisa fuma, o sistema está com vazamento.
  • Teste de regressão : um teste que foi escrito quando um bug foi corrigido. Ele garante que esse bug específico não ocorra novamente. O nome completo é "teste de não regressão". Também pode ser um teste feito antes da alteração de um aplicativo para garantir que o aplicativo ofereça o mesmo resultado.

Para isso, adicionarei:

  • Teste de aceitação : teste se um recurso ou caso de uso está implementado corretamente. É semelhante a um teste de integração, mas com foco no caso de uso a ser fornecido, e não nos componentes envolvidos.

  • Teste do sistema : testa um sistema como uma caixa preta. Dependências em outros sistemas são frequentemente zombadas ou stubadas durante o teste (caso contrário, seria mais um teste de integração).

  • Verificação antes do voo : testes repetidos em um ambiente semelhante à produção, para aliviar a síndrome do 'constrói na minha máquina'. Muitas vezes, isso é realizado através de um teste de aceitação ou fumaça em um ambiente semelhante à produção.


250
O teste de fumaça antecede a eletrônica em um século e vem do encanamento, quando um sistema de tubos foi preenchido por uma fumaça real e depois verificado visualmente. Se fumou, estava com vazamento.
SnakE

2
Os testes de regressão também são usados ​​para alterações de recursos, não apenas para correção de erros. A resposta da Nikita abaixo é uma definição mais abrangente.
BobRodes

25
@AndyM O plano de fundo do 'Teste de fumaça' é impreciso. O IIRC vem do encanamento, onde a fumaça é bombeada no sistema de tubulações após a construção (e antes de ser conectada ao abastecimento de água). Se houver fumaça, os canos não estão adequadamente fechados. Isso é menos prejudicial do que realmente deixar a água fluir e ver se existem poças (possivelmente danificando paredes / alvenaria no processo). É uma aproximação grosseira que o sistema não falhe catastroficamente. Um processo de desenvolvimento pode ser: "Build" passou? => "Teste de fumaça" passou? => "Teste de aceitação" passou => para a equipe de controle de qualidade para testes detalhados.
Cristian Diaconescu

4
Acredito que você cometeu um erro ao afirmar que um "Teste de regressão" é realmente uma abreviação de "Teste de não regressão"? Sou cético, em parte porque isso é pouco intuitivo e confuso (embora haja muitos termos), mas também a Wikipedia tem dois artigos separados sobre testes de regressão e não-regressão. O artigo sobre o teste de regressão ainda diz: Contraste com o teste de não regressão ... que visa verificar se, após a introdução ou atualização de um determinado aplicativo de software, a alteração teve o efeito pretendido.
Brian C

2
@ddaa Os testes de sanidade e de fumaça não são os mesmos. O teste de sanidade é realizado depois que a construção limpa o teste de fumaça e é aceito pela equipe de controle de qualidade para mais testes. O teste de sanidade verifica a funcionalidade principal com detalhes mais refinados.
Bharat

105
  • Teste de unidade : um teste automático para testar o funcionamento interno de uma classe. Deve ser um teste independente que não esteja relacionado a outros recursos.
  • Teste de integração : um teste automático realizado em um ambiente, semelhante aos testes de unidade, mas com recursos externos (banco de dados, acesso ao disco)
  • Teste de regressão : depois de implementar novos recursos ou correções, você testa novamente os cenários que funcionavam no passado. Aqui você cobre a possibilidade de seus novos recursos quebrarem os recursos existentes.
  • Teste de fumaça : primeiros testes nos quais os testadores podem concluir se continuarão testando.

2
A definição do teste de regressão não é exatamente exatamente como é. @ddaa define corretamente.
Robert Koritnik

A definição de Teste de Integração é definitivamente confusa. Por exemplo, na resposta aqui, stackoverflow.com/a/4904533/32453 , é mais definido como testar várias interações do seu código, não necessariamente necessitando de um banco de dados real (recurso externo) ... embora algumas pessoas o definam da maneira que você descreveu ... ahh terminologia. (Eu um pouco preferir a primeira definição, FWIW, testando múltiplas interações.)
rogerdpack

Por favor, veja minha pergunta: stackoverflow.com/questions/61711739/…
milad salimi

Isso responde ao título, mas não o de ferramentas para os dois últimos tipos de testes, para testes de fumaça ou regressão .
Peter Mortensen

90

Todos terão definições ligeiramente diferentes, e geralmente há áreas cinzentas. Contudo:

  • Teste de unidade: isso funciona um pouco (o mais isolado possível)?
  • Teste de integração: esses dois (ou mais) componentes funcionam juntos?
  • Teste de fumaça: todo esse sistema (o mais próximo possível de ser um sistema de produção) se encaixa razoavelmente bem? (ou seja, estamos razoavelmente confiantes de que não criará um buraco negro?)
  • Teste de regressão: reintroduzimos inadvertidamente alguns bugs que corrigimos anteriormente?

Como você coloca seus testes de integração em relação aos testes de unidade? Se myprj é o diretório principal do projeto e mypkgestá localizado em myprj, tenho os testes de unidade em myprj/tests/test_module1.pye meu pacote em myprj/mypkg. Isso funciona muito bem para testes de unidade, mas gostaria de saber se existe alguma convenção, devo seguir para onde os testes de integração devem residir?
alpha_989

1
@ alpha_989: Não sei qual seria a convenção para Python. No .NET, atualmente tenho o código de produção, testes de unidade e testes de integração em três projetos separados, pares um do outro - mas também existem muitas alternativas.
Jon Skeet

Ok .. obrigado. Eu poderia encontrar recomendação padrão além de olhar para outro projeto python. mas eu vou seguir a sua .. #
alpha_989

Por favor, veja minha pergunta: stackoverflow.com/questions/61711739/…
milad salimi

@miladsalimi: Por favor, não adicione comentários não relacionados apenas para obter atenção para outra pergunta. Vejo que você fez isso em outras quatro postagens - por favor, não.
Jon Skeet

51

Uma nova categoria de teste que acabei de tomar conhecimento é o teste de canário . Um teste canário é um teste automatizado e não destrutivo, executado regularmente em um ambiente ativo , de modo que, se algum dia falhar, algo realmente ruim aconteceu.

Exemplos podem ser:

  • Os dados que deveriam estar sempre disponíveis no desenvolvimento / irritadáveis ​​apareceram ao vivo ?
  • Falha ao executar um processo em segundo plano?
  • Um usuário pode fazer logon?

2
O site pode ser pingado? De maneira adequada, existe um serviço chamado Binary Canary.
Dan Dascalescu

15
O nome vem da mineração de carvão: leve o canário com você "para baixo". Quando o farejar, saia rápido. Canárias são muito sensíveis a pequenas concentrações de gases nocivos e morrem antes que os níveis de concentração se tornem tóxicos para os seres humanos. Se um teste das Canárias falhar, corrija-o rapidamente, pois será apenas uma questão de tempo até que o LIVE falhe.
Robino

1
A maneira como usamos o teste Canary no meu trabalho é transferir alguns clientes para uma nova versão, em vez de todos de uma vez. Se os primeiros clientes sobreviverem, podemos adicionar o resto. Esses primeiros são os canários.
00prometheus 15/09/16

2
@ 00prometheus, isso é teste beta.
precisa saber é o seguinte

1
@ HarveyLin, embora um teste Canary seja necessariamente um teste que evita desastres, é claro que não é usado apenas dessa maneira. Mas a regra geral é "teste se isso está funcionando porque é crítico". Obviamente, todo teste tem quase o mesmo objetivo, mas o conceito é muito específico. No seu caso, eu não contaria todos os testes como canários.
Charles Roberto Canato

12

Resposta de um dos melhores sites para técnicas de teste de software:

Tipos de teste de software - lista completa clique aqui

Digite a descrição da imagem aqui

É uma descrição bastante longa, e não vou colá-la aqui: mas pode ser útil para quem deseja conhecer todas as técnicas de teste.


10

Teste de unidade: verificação do componente em particular (ou seja, classe) criado ou modificado, conforme projetado. Este teste pode ser manual ou automatizado, mas não ultrapassa os limites do componente.

Teste de integração: Verificando se a interação de componentes específicos funciona como projetado. Testes de integração podem ser realizados no nível da unidade ou no nível do sistema. Esses testes podem ser manuais ou automatizados.

Teste de regressão: verificando se novos defeitos não são introduzidos no código existente. Esses testes podem ser manuais ou automatizados.

Dependendo do seu SDLC ( cascata , RUP , ágil etc.), determinados testes podem ser realizados em 'fases' ou todos podem ser realizados, mais ou menos, ao mesmo tempo. Por exemplo, o teste de unidade pode ser limitado aos desenvolvedores que entregam o código aos testadores para testes de integração e regressão. No entanto, outra abordagem pode ter desenvolvedores fazendo testes de unidade e algum nível de integração e testes de regressão (usando uma abordagem TDD juntamente com a integração contínua e testes automatizados de unidade e regressão).

O conjunto de ferramentas dependerá amplamente da base de código, mas há muitas ferramentas de código aberto para testes de unidade (JUnit). O QTP (Mercury) da HP ou o Silk Test da Borland são ferramentas para testes automatizados de integração e regressão.


Esta é uma das poucas respostas que inclui algo sobre ferramentas.
Peter Mortensen

8

Teste de unidade : o teste de um módulo individual ou componente independente em um aplicativo é conhecido por teste de unidade. O teste de unidade será feito pelo desenvolvedor.

Teste de integração : combinando todos os módulos e testando o aplicativo para verificar se a comunicação e o fluxo de dados entre os módulos estão funcionando corretamente ou não. Este teste também foi realizado pelos desenvolvedores.

Teste de fumaça Em um teste de fumaça, eles verificam a aplicação de maneira rasa e ampla. Nos testes de fumaça, eles verificam a principal funcionalidade do aplicativo. Se houver algum problema de bloqueador no aplicativo, eles reportarão à equipe de desenvolvedores, e a equipe de desenvolvimento corrigirá e corrigirá o defeito e devolvê-lo à equipe de teste. Agora, a equipe de teste verificará todos os módulos para verificar se as alterações feitas em um módulo afetarão ou não o outro. Nos testes de fumaça, os casos de teste são roteirizados.

Teste de regressão executando os mesmos casos de teste repetidamente para garantir que o módulo inalterado não cause nenhum defeito. Os testes de regressão são submetidos a testes funcionais


Isso responde ao título, mas não o de ferramentas para os dois últimos tipos de testes, para testes de fumaça ou regressão. Ele também repete as respostas anteriores - pode ser único respondendo à pergunta sobre ferramentas.
Peter Mortensen

7

TESTE DE REGRESSÃO

"Um teste de regressão executa novamente os testes anteriores no software alterado para garantir que as alterações feitas no software atual não afetem a funcionalidade do software existente."


18
De onde você está citando?
Daryl

4
De acordo com esta página , que a citação veio do artigo da Wikipédia "Teste de software" embora pareça que a passagem foi alterada em algum momento desde 2010.
Zach Lysobey

De qualquer forma, o WP não é uma fonte válida. As fontes referenciadas podem ser válidas. Não há fontes válidas referenciadas no WP, nem nos artigos nem nas páginas de discussão, que apoiariam a alegação de que o "não" faz alguma diferença. Comparei os snippets de texto nas listas de resultados das pesquisas no Google Livros para ambos "regression test"e "non-regression test". É o mesmo.
Rainald62

Isso responde (parte do) título, mas não o que diz respeito às ferramentas dos dois últimos tipos de testes, para testes de fumaça ou regressão. Ele também repete as respostas anteriores - pode ser único respondendo à pergunta sobre ferramentas.
Peter Mortensen

7

Eu só queria adicionar e dar um pouco mais de contexto sobre por que temos esses níveis de teste, o que eles realmente significam com exemplos

Mike Cohn, em seu livro “Successful with Agile”, criou a “Testing Pyramid” como uma maneira de abordar testes automatizados em projetos. Existem várias interpretações desse modelo. O modelo explica que tipo de testes automatizados precisam ser criados, com que rapidez eles podem dar feedback sobre o aplicativo em teste e quem os escreve. Existem basicamente três níveis de teste automatizado necessários para qualquer projeto e são os seguintes.

Testes de unidade - testam o menor componente do seu aplicativo de software. Isso poderia literalmente ser uma função em um código que calcula um valor com base em algumas entradas. Essa função faz parte de várias outras funções da base de código de hardware / software que compõe o aplicativo.

Por exemplo - vamos usar um aplicativo de calculadora baseado na web. Os menores componentes deste aplicativo que precisam ser testados em unidade podem ser uma função que executa adição, outro que executa subtração e assim por diante. Todas essas pequenas funções juntas formam o aplicativo da calculadora.

Historicamente, o desenvolvedor grava esses testes, pois geralmente são escritos na mesma linguagem de programação que o aplicativo de software. Estruturas de teste de unidade, como JUnit e NUnit (para java), MSTest (para C # e .NET) e Jasmine / Mocha (para JavaScript) são usadas para esse fim.

A maior vantagem dos testes de unidade é que eles são executados muito rapidamente sob a interface do usuário e podemos obter um feedback rápido sobre o aplicativo. Isso deve incluir mais de 50% dos seus testes automatizados.

Testes de API / integração - Eles testam vários componentes do sistema de software juntos. Os componentes podem incluir bancos de dados de teste, APIs (Application Programming Interface), ferramentas e serviços de terceiros junto com o aplicativo.

Por exemplo - no exemplo da calculadora acima, o aplicativo Web pode usar um banco de dados para armazenar valores, usar APIs para fazer algumas validações no servidor e usar uma ferramenta / serviço de terceiros para publicar resultados na nuvem e disponibilizá-lo em diferentes plataformas.

Historicamente, um desenvolvedor ou controle de qualidade técnico escreveria esses testes usando várias ferramentas, como Postman, SoapUI, JMeter e outras ferramentas como o Testim.

Eles são executados muito mais rapidamente do que os testes de interface do usuário, pois ainda são executados sob o capô, mas podem consumir um pouco mais de tempo do que os testes de unidade, pois precisam verificar a comunicação entre os vários componentes independentes do sistema e garantir uma integração perfeita. Isso deve incluir mais de 30% dos testes automatizados.

Testes de interface do usuário - Finalmente, temos testes que validam a interface do usuário do aplicativo. Esses testes geralmente são escritos para testar fluxos de ponta a ponta através do aplicativo.

Por exemplo - No aplicativo da calculadora, pode haver um fluxo de ponta a ponta, abrindo o navegador-> Inserindo o URL do aplicativo da calculadora -> Fazendo login com nome de usuário / senha -> Abrindo o aplicativo da calculadora -> Executando algumas operações na calculadora -> verificar esses resultados na interface do usuário -> Sair do aplicativo. Esse poderia ser um fluxo de ponta a ponta que seria um bom candidato à automação da interface do usuário.

Historicamente, os QAs técnicos ou os testadores manuais escrevem testes de interface do usuário. Eles usam estruturas de código aberto como Selenium ou plataformas de teste de interface do usuário como o Testim para criar, executar e manter os testes. Esses testes fornecem mais feedback visual, como você pode ver como os testes estão sendo executados, a diferença entre os resultados esperados e os reais através de capturas de tela, logs e relatórios de teste.

A maior limitação dos testes de interface do usuário é que eles são relativamente lentos se comparados aos testes de nível de unidade e API. Portanto, ele deve incluir apenas 10 a 20% dos testes automatizados gerais.

Os próximos dois tipos de testes podem variar com base no seu projeto, mas a idéia é:

Testes de fumaça

Isso pode ser uma combinação dos três níveis de teste acima. A idéia é executá-lo durante cada check-in de código e garantir que as funcionalidades críticas do sistema ainda estejam funcionando conforme o esperado; após as novas alterações de código serem mescladas. Eles normalmente precisam ser executados com 5 a 10 minutos para obter um feedback mais rápido sobre falhas

Testes de regressão

Eles geralmente são executados uma vez por dia, pelo menos, e abrangem várias funcionalidades do sistema. Eles garantem que o aplicativo ainda esteja funcionando conforme o esperado. São mais detalhes do que os testes de fumaça e abrangem mais cenários do aplicativo, incluindo os não críticos.


Essa resposta poderia ser melhorada respondendo à pergunta sobre ferramentas para teste de fumaça ou regressão .
Peter Mortensen

5

O teste de unidade é direcionado para a menor parte possível da implementação. Em Java, isso significa que você está testando uma única classe. Se a classe depende de outras classes, elas são falsificadas.

Quando seu teste chama mais de uma classe, é um teste de integração .

Os conjuntos de testes completos podem levar muito tempo para serem executados; portanto, após uma alteração, muitas equipes executam alguns testes rápidos para concluir para detectar quebras significativas. Por exemplo, você quebrou os URIs em recursos essenciais. Estes são os testes de fumaça .

Os testes de regressão são executados em todas as construções e permitem refatorar efetivamente capturando o que você quebra. Qualquer tipo de teste pode ser um teste de regressão, mas acho que os testes de unidade são muito úteis para encontrar a fonte da falha.


Isso responde ao título, mas não o de ferramentas para os dois últimos tipos de testes, para testes de fumaça ou regressão. Ele também repete as respostas anteriores - pode ser único respondendo à pergunta sobre ferramentas.
Peter Mortensen

4
  • Teste de integração: o teste de integração é o outro elemento de integração
  • Teste de fumaça: O teste de fumaça também é conhecido como teste de versão de compilação. O teste de fumaça é o processo inicial de teste para verificar se o software em teste está pronto / estável para testes adicionais.
  • Teste de regressão: o teste de regressão é um teste repetido . Se um novo software é efetuado em outro módulo ou não.
  • Teste de unidade: É um teste de caixa branca. Somente desenvolvedores envolvem nele

Isso responde ao título, mas não o de ferramentas para os dois últimos tipos de testes, para testes de fumaça ou regressão. Ele também repete as respostas anteriores - pode ser único respondendo à pergunta sobre ferramentas.
Peter Mortensen

2

Teste de unidade: sempre é executado pelo desenvolvedor após o desenvolvimento para descobrir o problema do lado do teste antes de preparar qualquer requisito para o controle de qualidade.

Teste de integração: significa que o testador precisa verificar a verificação do módulo para o submódulo quando algumas saídas de dados / funções são direcionadas para um módulo para outro módulo. Ou no seu sistema, se estiver usando uma ferramenta de terceiros que integra os dados do sistema.

Teste de fumaça: testador executado para verificar se o sistema está testando em alto nível e tentando descobrir o bug da rolha antes que as alterações ou o código sejam ativados.

Teste de regressão: O testador executou a regressão para verificação da funcionalidade existente devido a alterações implementadas no sistema para aprimoramento recente ou alterações no sistema.


Não precisamos criar o teste antes de fazer o desenvolvimento real?
precisa

@VinShahrdar, você está falando sobre testes de unidade?
quer

sim. Normalmente, crio meus testes de unidade antes de escrever o código de produção. É assim que você deve fazer isso, correto?
Vin Shahrdar

1
Sim. Mas o teste de unidade também é executado antes do controle de qualidade enfrentado pelo desenvolvedor. Antes de implantar o código no servidor de controle de qualidade, o desenvolvedor deve sempre executar testes de unidade
Krunal

2

Teste de Unidade

O teste de unidade geralmente é feito pelo lado dos desenvolvedores, enquanto os testadores são parcialmente desenvolvidos nesse tipo de teste, em que o teste é feito unidade a unidade. Nos casos de teste Java JUnit , também é possível testar se o código escrito foi perfeitamente projetado ou não.

Teste de integração:

Esse tipo de teste é possível após o teste da unidade, quando todos / alguns componentes estão integrados. Esse tipo de teste garantirá que, quando os componentes forem integrados, eles afetem as capacidades ou funcionalidades de trabalho uns dos outros?

Teste de fumaça

Esse tipo de teste é realizado no final quando o sistema é integrado com sucesso e pronto para ser utilizado no servidor de produção.

Esse tipo de teste garantirá que todas as funcionalidades importantes do início ao fim estejam funcionando bem e que o sistema esteja pronto para implantar no servidor de produção.

Teste de regressão

Esse tipo de teste é importante para testar se defeitos não intencionais / indesejados não estão presentes no sistema quando o desenvolvedor corrigiu alguns problemas. Esse teste também garante que todos os erros sejam resolvidos com sucesso e, por isso, nenhum outro problema ocorreu.


Isso responde ao título, mas não o de ferramentas para os dois últimos tipos de testes, para testes de fumaça ou regressão. Ele também repete as respostas anteriores - pode ser único respondendo à pergunta sobre ferramentas.
Peter Mortensen

2

Os testes de fumaça e sanidade são realizados após a criação do software para identificar se é necessário iniciar o teste. A sanidade pode ou não ser executada após o teste de fumaça. Eles podem ser executados separadamente ou ao mesmo tempo - a sanidade é imediatamente após a fumaça.

Como o teste de sanidade é mais profundo e leva mais tempo, na maioria dos casos vale a pena ser automatizado.

O teste de fumaça geralmente não leva mais que 5 a 30 minutos para execução. É mais geral: verifica um pequeno número de funcionalidades principais de todo o sistema, para verificar se a estabilidade do software é boa o suficiente para testes adicionais e se não há problemas, impedindo a execução dos casos de teste planejados.

O teste de sanidade é mais detalhado que a fumaça e pode levar de 15 minutos a um dia inteiro, dependendo da escala da nova compilação. É um tipo mais especializado de teste de aceitação, realizado após a progressão ou novo teste. Ele verifica os principais recursos de certas novas funcionalidades e / ou correções de bugs, juntamente com alguns intimamente relacionados a eles, a fim de verificar se eles estão funcionando conforme a lógica operacional necessária, antes que o teste de regressão possa ser executado em uma escala maior.


Isso elabora um pouco, mas não sobre ferramentas para os dois últimos tipos de testes, para testes de fumaça ou regressão . Pode ser único respondendo à pergunta sobre ferramentas.
Peter Mortensen

1

Já existem algumas boas respostas, mas eu gostaria de refiná-las ainda mais:

O teste de unidade é a única forma de teste de caixa branca aqui. Os outros são testes de caixa preta. Teste de caixa branca significa que você conhece a entrada; você conhece o funcionamento interno do mecanismo e pode inspecioná-lo e conhece a saída. Com o teste da caixa preta, você sabe apenas qual é a entrada e qual deve ser a saída.

Claramente, o teste de unidade é o único teste de caixa branca aqui.

  • O teste de unidade testa partes específicas do código. Geralmente métodos.
  • Teste de integração testa se o seu novo recurso pode ser integrado a todo o resto.
  • Teste de regressão. Este é um teste feito para garantir que você não tenha quebrado nada. Tudo o que costumava funcionar ainda deve funcionar.
  • O teste de fumaça é feito como um teste rápido para garantir que tudo esteja correto antes de você se envolver nos testes mais vigorosos.

5
O teste de unidade não é necessariamente uma caixa branca. Alguns dos melhores testes de unidade que eu já vi são essencialmente exemplos extraídos dos requisitos, especificando os resultados esperados independentemente de quaisquer conceitos de implementação.
joel.neely

1
Além disso, seus testes de unidade são incluídos nos testes de regressão; portanto, os testes de regressão não são testes de caixa branca ou preta. Eu diria até que os testes de integração e fumaça podem ser testes em branco ou em caixa preta.
Lieven Keersmaekers #: 6309

1
Eu teria que discordar disso. Testar uma implementação de padrão de design é uma forma de teste de integração e é um teste de caixa branca.
Hazok

Isso responde ao título, mas não o de ferramentas para os dois últimos tipos de testes, para testes de fumaça ou regressão . Ele também repete as respostas anteriores - pode ser único respondendo à pergunta sobre ferramentas.
Peter Mortensen

1

Os testes de fumaça já foram explicados aqui e são simples. Os testes de regressão são submetidos a testes de integração.

Testes automatizados podem ser divididos em apenas dois.

Testes de unidade e testes de integração (isso é tudo o que importa)

Eu chamaria de usar a frase "teste longo" (LT) para todos os testes, como testes de integração, testes funcionais, testes de regressão, testes de interface do usuário, etc. E testes de unidade como "teste curto".

Um exemplo do LT pode ser o carregamento automático de uma página da web, o login na conta e a compra de um livro. Se o teste for aprovado, é mais provável que seja executado no site ao vivo da mesma maneira (daí a referência 'sono melhor'). Long = distância entre a página da web (início) e o banco de dados (final).

E este é um ótimo artigo que discute os benefícios do teste de integração (teste longo) sobre o teste de unidade .


1

Teste de regressão - é um tipo de teste de software em que tentamos cobrir ou verificar a correção de bugs . A funcionalidade em torno da correção de bug não deve ser alterada ou alterada devido à correção fornecida. Os problemas encontrados nesse processo são chamados de problemas de regressão .

Teste de fumaça: é um tipo de teste feito para decidir se aceita a compilação / software para outros testes de controle de qualidade.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.