caixa preta vs Branco caixa Testing

StackOverflow https://stackoverflow.com/questions/402161

Pergunta

Que tipo de teste que você diria deve ser a ênfase (para testadores / QAs), e por quê?

A configuração rápida de definições da wikipedia:

teste de caixa preta

  • leva uma perspectiva externa do objeto de teste para casos de teste derivam. Estes testes podem ser funcional ou n funcional, embora geralmente funcional. O designer de teste seleciona entrada válidos e inválidos e determina a saída correta. Não há conhecimento da estrutura interna do objeto de teste.

White teste de caixa

  • usa uma perspectiva interna do sistema para projetar casos de teste com base na estrutura interna. Ele requer habilidades de programação para identificar todos os caminhos através do software. O testador escolhe entradas de casos de teste para caminhos de exercício através do código e determina as saídas apropriadas. Em testes de hardware eléctrica, cada nó de um circuito pode ser sondado e medido; um exemplo é o teste em-circuito (TIC).

Edit: Só para esclarecer um pouco mais, percebo que ambos são importantes, mas geralmente eles são separados entre dev e QA.

É de conhecimento interno importante para o testador / QA? Já ouvi argumentos que o teste com este conhecimento em mente que lhes permite melhor teste para os problemas, mas eu também ouvi argumentos que este conhecimento pode distrair a partir de necessidades funcionais e promover "o teste para o código" em vez de à solução pretendida .

Foi útil?

Solução

  • teste de caixa preta deve ser a ênfase para testadores / QA.
  • teste de caixa branca deve ser a ênfase para os desenvolvedores (ou seja, testes de unidade).
  • As outras pessoas que responderam a esta questão parecia ter interpretado a pergunta como O que é mais importante, teste de caixa branca ou teste de caixa preta . Eu também acredito que ambos são importantes, mas você pode querer verificar para fora este href="https://pdfs.semanticscholar.org/7eee/629b22cd3db63296cac13a0c37cb0a7235f6.pdf" rel="nofollow noreferrer"> IEEE artigo que afirma que teste de caixa branca é mais importante.

Outras dicas

White Box Testing é igual a Unidade de Teste de Software. A garante que o código que ele escreveu está a funcionar correctamente de acordo com os requisitos de nível detalhados antes de integrá-lo no sistema de desenvolvedor ou um testador de nível de desenvolvimento (por exemplo, outro desenvolvedor).

Black Box Testing é igual Teste de Integração. O testador garante que o sistema funciona de acordo com os requisitos de um nível funcional.

As duas abordagens de teste são igualmente importante na minha opinião.

Um teste de unidade completa vai pegar defeitos em fase de desenvolvimento e não após o software foi integrado ao sistema. Um teste de caixa preta nível do sistema irá garantir que todos os módulos de software se comportar corretamente quando integrados em conjunto. Um teste de unidade em fase de desenvolvimento não capturar esses defeitos uma vez que os módulos são geralmente desenvolvido independente um do outro.

Black Box

1 Concentra-se a funcionalidade do sistema Centra-se na estrutura (Programa) do sistema

2 Técnicas utilizadas são:

· Equivalência particionamento

· Análise Boundary-value

· Erro adivinhar

· Condições de corrida

· Causa-efeito gráficos

· testes de Sintaxe

· Teste de transição de Estado

· Graph matriz

Tester pode ser não técnico

ajuda a identificar a imprecisão e contradição em especificações funcionais

White Box

As técnicas utilizadas são:

· Caminho Base Testing

· Fluxo Graph Notação

· Estrutura de Controle Testing

  1. condição de teste

  2. teste de fluxo de dados

· Testes de loop

  1. Loops simples

  2. Nested Loops

  3. concatenadas Loops

  4. não estruturados Loops

    Tester deve ser técnico

    Ajuda a identificar as questões lógicas e de codificação.

QA deve se concentrar em Caixa preta de teste . O principal objetivo do QA é testar o que o sistema faz (faça características atender aos requisitos?), E não como ele faz isso.

De qualquer forma, deve ser difícil para QA para fazer teste de caixa branca como a maioria dos caras QA não são caras tecnologia, para que eles costumam testar recursos através da interface do usuário (como usuários).

Um passo adiante, acho que developpers também deve se concentrar em Caixa preta de teste . Não concordo com esta associação generalizada entre testes unitários e testes de caixa branca, mas pode ser apenas uma questão de um vocabulário / escala. Na escala de um teste de unidade, o Sistema de Teste Em é uma classe / método que tem contrato (através da sua assinatura) e o ponto importante é testar o que faz, não como. Além disso teste de caixa branca implica que você sabe como o método vai encher seu contrato, que parece incompatile com TDD para mim.

IMHO se o seu SUT é tão complexo que você precisa fazer teste de caixa branca, geralmente é tempo para refatorar.

"Both" foi dito acima, e é a resposta óbvia ... mas IMO, teste de caixa branca vai muito além de testes de unidade desenvolvedor (althoughI suponho que poderia depender de onde você traçar a linha entre branco e preto). Por exemplo, a análise de cobertura de código é uma abordagem comum caixa branca - ou seja, executar alguns cenários ou testes, e examinar os resultados que procuram buracos no teste. Mesmo se testes de unidade tem 100% cc, medindo cc em cenários de usuários comuns podem revelar código que pode potencialmente precisam de testes ainda mais.

Outro lugar onde o teste de caixa branca ajuda a analisar os tipos de dados, constantes e outras informações para procurar limites, valores especiais, etc. Por exemplo, se um aplicativo tem uma entrada que leva uma entrada numérica, um bb única abordagem poderia exigir o testador "adivinhar" em que valores seria bom para o teste, enquanto que uma abordagem wb pode revelar que todos os valores entre 1-256 são tratados de uma maneira, enquanto valores maiores são tratados de outra maneira ... e talvez o número 42 tem ainda outro caminho de código.

Assim, para responder à pergunta original - tanto bb e WB são essenciais para um bom teste.

Na minha experiência, a maioria dos desenvolvedores naturalmente migrar para teste de caixa branca. Uma vez que precisamos para garantir que o algoritmo subjacente é "correta", que tendem a se concentrar mais nas partes internas. Mas, como tem sido apontado, tanto teste de caixa branca e preta é importante.

Portanto, eu prefiro ter testadores de se concentrar mais em testes de caixa preta, a cobertura para o fato de que a maioria dos desenvolvedores realmente não fazê-lo, e muitas vezes não são muito bons nisso.

Isso não quer dizer que os testadores devem ser mantidos no escuro sobre como o sistema funciona, só que eu prefiro-los a se concentrar mais no domínio do problema e como real os usuários interagem com o sistema, não se a função SomeMethod ( int x) vai jogar corretamente uma exceção se x é igual a 5.

É um pouco de uma porta aberta, mas no final, ambos são igualmente importantes.

O que é pior?

  1. software que faz o que precisa fazer, mas internamente tem problemas?

  2. software que é suposto para trabalhar se você olhar para as fontes, mas não tem?

A minha resposta: Nem é totalmente aceitável, mas o software não pode ser provado ser 100% livre de erros. Então você vai ter que fazer alguns trade-offs. Opção dois é mais diretamente perceptível para os clientes, de modo que você vai ter problemas com que, mais cedo. No longo prazo, opção um vai ser problemático.

Black Box Testing: testes de caixa preta é apenas a observação não há necessidade de conhecimento interno ou estrutura de produto de software. apenas colocando entrada de dados válidos e inválidos e esperar o resultado correto. aqui testador de encontrar o defeito, mas incapaz de encontrar a localização da caixa de defect.black testes feito em todos os níveis de testes.

caixa preta tecniques de teste são: 1. partição equivalance 2. Análise de Valor Limite 3. tabela de decisão 4. Estado Diagrama de Transição 4. Use diagrama de casos

White Box Testing: Caixa branca está testando ele requer o conhecimento de lógica interna ea estrutura do produto de software. aqui vamos verificar o loop, condição e ramo. aqui encontramos não só o defeito, mas também e localização do defeito.

caixa branca Técnicas de Teste: 1. Declaração de Cobertura 2. Decisão Cobertura 3. Poder de Cobertura 4. Caminho de Cobertura.

  • Normalmente, o teste de caixa-branca não é possível para os testadores. Assim, a única resposta viável para testadores é enfatizar abordagem caixa-preta.

  • No entanto, com orientada a aspectos-programação e metodologia de projeto-a-contrato, quando os objetivos de teste são programados no código-alvo como contratos (visto a partir da visão estática de um programa), e / ou quando o testando lógica temporal é programado para o código como cortes transversais (vista dinâmico da lógica de teste), o teste de caixa branca iria tornar-se não só é possível, mas também uma tomada preferida para testadores. Dado que disse, ele precisa ser um take-exigindo perícia, os testadores precisam ser não apenas testadores bom, mas também bons programadores ou mais do que bons programadores.

Black Box Testing é um método de teste de software no qual a estrutura / design / implementação interna do item que está sendo testado não é conhecido para o testador. White Box Testing é um método de teste de software no qual a estrutura / design / implementação interna do item que está sendo testado é conhecido para o testador.

O que constitui "conhecimento interno?" Faz saber que tal e tal algoritmo foi utilizado para resolver um problema qualificar ou faz o testador tem que ver cada linha de código para que seja "interna?"

Eu acho que em qualquer caso de teste, não se deve esperar resultados fornecidos pelo especificação utilizada e não determinado pela forma como o testador decide interpretar a especificação, pois isso pode levar a problemas onde cada pensa que eles estão certos e culpando o outro pela problema.

  • * teste de caixa preta: é o teste ao nível do sistema para verificar a funcionalidade do sistema, para garantir que o sistema executa todas as funções que ele foi projetado para, Sua principalmente a defeitos desvendar encontrado no ponto do usuário. Sua melhor contratar um testador profissional para caixa preta seu sistema ', coz o desenvolvedor normalmente testa com uma perspectiva de que os códigos que ele havia escrito é bom e atende às exigências funcionais dos clientes para que ele pudesse perder um monte de coisas (I don 't quero ofender ninguém)
  • Whitebox é o primeiro teste que é feito nas SDLC.This é a bugs desvendar como erros de execução e errrors compilação que pode ser feito tanto por testadores ou pelo próprio desenvolvedor, mas eu acho que é sempre melhor do que a pessoa que escreveu o testa código it.He entende-los mais do que outra pessoa. *

Aqui está o meu 5 centavos:

Como um desenvolvedor, eu testes principalmente gravação para métodos (em uma classe), como testes de caixa branca, simples, porque eu não quero que o meu teste para quebrar só porque eu mudar as obras internas do meu código.

Eu só quero meus testes para quebrar se o meu método de mudanças de comportamento (por exemplo, retorna um resultado diferente do que antes).

Ao longo dos últimos 20 anos de desenvolvimento, eu simples se cansou de fazer up-to trabalho dupla só porque meus testes de unidade foi fortemente vinculado ao código e eu preciso para manter tanto o código do aplicativo e código de teste.

Eu acho que fazer a dissociação código (também quando os testes de código) é uma prática muito boa.

Outra 5 centavos: Eu mal nunca use zombando frameworks, porque quando eu encontrá-lo, necessariamente, a algo simulada eu prefiro dissociar o meu código em vez disso - e, sim, em muitos casos, que é muito possível (especialmente se você não está trabalhando em código legado ): -)

* Black-Box testes: Se o código fonte não está disponível, em seguida, dados de teste é baseado na função do software sem levar em conta como ele foi implementado. textExamples -novo de teste de caixa-preta são: limite testes valor e equivalência de particionamento

.

* White-Box testes: Se o código-fonte do sistema em teste está disponível, em seguida, os dados de teste é baseado na estrutura deste código-fonte. -Exemplos de ensaio de caixa branca são:. Testes caminho e dados de teste de fluxo

Simples ... teste de caixa-preta é também conhecido como teste de integração ou teste cortina de fumaça. Isto é principalmente aplicado em um ambiente distribuído que dependem de arquitetura orientada a eventos. Você testar um serviço baseado em outro serviço para ver todos os cenários possíveis. Aqui você não pode prever completamente todas as saídas possíveis porque cada componente do aplicativo SOA / Empresa são destinados a funcionar de forma autônoma. Isto pode ser referido como de Alto Nível testing

enquanto

teste de caixa branca refere-se ao teste de unidade. onde todos os cenários esperados e saída pode ser efetivamente previsto. Entrada isto e output.This esperados pode ser referido como o teste de baixo nível

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