Teste de caixa branca: um guia completo com técnicas, exemplos e ferramentas

white box testing complete guide with techniques

O que é o teste da caixa branca?

Se formos pela definição, “teste de caixa branca” (também conhecido como teste transparente, caixa de vidro ou teste estrutural) é uma técnica de teste que avalia o código e a estrutura interna de um programa.

O teste de caixa branca envolve a análise da estrutura do código. Quando você conhece a estrutura interna de um produto, podem ser realizados testes para garantir que as operações internas sejam realizadas de acordo com a especificação. E todos os componentes internos foram adequadamente exercitados.

O que você aprenderá:

• Minha experiência
  • Cobertura
  • Por que realizamos WBT?
  • Este teste requer habilidades de programação detalhadas?
  • Limitações
• Diferença entre testes de caixa branca e caixa preta
• Etapas para realizar WBT
• Tipos e técnicas de teste de caixa branca
• Exemplo de teste de caixa branca
• Ferramentas de teste de caixa branca
• Conclusão
• Leitura recomendada

Minha experiência

Já se passou quase uma década desde que comecei a trabalhar no campo de teste de software e até agora notei que os testadores são os mais entusiasmados em toda a indústria de software.

A principal razão por trás disso é - o testador sempre tem algo em seu escopo para aprender. Seja um domínio, processo ou tecnologia, um testador pode ter um desenvolvimento completo se desejar.

Mas como dizem “Há sempre um lado mais escuro” .

Os testadores também evitam um tipo de teste que consideram muito complicado e fácil para o desenvolvedor. Sim, o “Teste da Caixa Branca”.

Cobertura

O teste da caixa branca é a cobertura da especificação no código:

1 Cobertura de código

2. Cobertura do segmento: Certifique-se de que cada instrução de código seja executada uma vez.

3. Cobertura de filial ou teste de nó: A cobertura de cada ramificação de código de todas as possíveis era.

4. Cobertura de condição composta: Para várias condições, teste cada condição com vários caminhos e combinação dos diferentes caminhos para alcançar essa condição.

5. Teste de caminho básico: Cada caminho independente no código é usado para teste.

6. Teste de fluxo de dados (DFT): Nesta abordagem, você rastreia as variáveis ​​específicas através de cada cálculo possível, definindo assim o conjunto de caminhos intermediários através do código. DFT tende a refletir dependências, mas é principalmente por meio de sequências de manipulação de dados. Em suma, cada variável de dados é rastreada e seu uso é verificado. Essa abordagem tende a descobrir bugs como variáveis ​​usadas, mas não inicializadas, ou declaradas, mas não usadas, e assim por diante.

7. Teste de Caminho: O teste de caminho é onde todos os caminhos possíveis através do código são definidos e cobertos. É uma tarefa demorada.

8. Teste de Loop: Essas estratégias estão relacionadas ao teste de loops únicos, loops concatenados e loops aninhados. Os loops e valores de código independentes e dependentes são testados por esta abordagem.

Por que realizamos WBT?

Para garantir:

• Que todos os caminhos independentes dentro de um módulo foram exercitados pelo menos uma vez.
• Todas as decisões lógicas verificadas em seus valores verdadeiros e falsos.
• Todos os loops executados em seus limites e dentro de seus limites operacionais validade de estruturas de dados internas.

Para descobrir os seguintes tipos de bugs:

• O erro lógico tende a se infiltrar em nosso trabalho quando projetamos e implementamos funções, condições ou controles que estão fora do programa
• Os erros de design devido à diferença entre o fluxo lógico do programa e a implementação real
• Erros tipográficos e verificação de sintaxe

Este teste requer habilidades de programação detalhadas?

Precisamos escrever casos de teste que garantem a cobertura completa da lógica do programa.

Para isso, precisamos conhecer bem o programa, ou seja, devemos conhecer a especificação e o código a ser testado. Conhecimento de linguagens de programação e lógica é necessário para este tipo de teste.

Limitações

Não é possível testar todos os caminhos dos loops no programa. Isso significa que testes exaustivos são impossíveis para sistemas grandes.

Isso não significa que o WBT não seja eficaz. Ao selecionar caminhos lógicos importantes e estrutura de dados para teste é praticamente possível e eficaz.

Diferença entre testes de caixa branca e caixa preta

Para colocá-lo em termos simples:

No teste da caixa preta, testamos o software do ponto de vista do usuário, mas na caixa branca, vemos e testamos o código real.

No teste de caixa preta, realizamos o teste sem ver o código interno do sistema, mas no WBT vemos e testamos o código interno.

A técnica de teste de caixa branca é usada tanto pelos desenvolvedores quanto pelos testadores. Isso os ajuda a entender qual linha de código é realmente executada e qual não é. Isso pode indicar que há uma lógica ausente ou um erro de digitação, o que pode levar a algumas consequências negativas.

Leitura recomendada => Um guia completo para testes de caixa preta

Etapas para realizar WBT

Passo 1 - Compreender a funcionalidade de um aplicativo por meio de seu código-fonte. O que significa que um testador deve ser bem versado na linguagem de programação e nas outras ferramentas, bem como nas técnicas usadas para desenvolver o software.

Passo 2 - Crie os testes e execute-os.

Quando discutimos o conceito de teste, “ cobertura ”É considerado o fator mais importante. Aqui, explicarei como obter cobertura máxima do contexto do teste de caixa branca.

Leia também=> Gráfico de causa e efeito - Técnica de escrita de caso de teste dinâmico para cobertura máxima

Tipos e técnicas de teste de caixa branca

Existem vários tipos e métodos diferentes para cada tipo de teste de caixa branca.

Veja a imagem abaixo para sua referência.

Hoje, vamos nos concentrar principalmente no tipos de teste de execução de 'técnica de caixa branca de teste de unidade'.

3 Técnicas de teste da caixa branca principal:

1. Cobertura de Declaração
2. Cobertura de filial
3. Cobertura do Caminho

Observe que a cobertura de declaração, ramificação ou caminho não identifica nenhum bug ou defeito que precise ser corrigido. Ele apenas identifica as linhas de código que nunca são executadas ou permanecem intocadas. Com base nisso, mais testes podem ser focados.

Vamos entender essas técnicas uma a uma com um exemplo simples.

# 1) Cobertura da declaração:

Em uma linguagem de programação, uma instrução nada mais é que a linha de código ou instrução para o computador entender e agir de acordo. Uma instrução se torna uma instrução executável quando é compilada e convertida no código do objeto e executa a ação quando o programa está em um modo de execução.

Conseqüentemente “Cobertura de Declaração” , como o próprio nome sugere, é o método de validar se cada linha do código é executada pelo menos uma vez.

# 2) Cobertura da filial:

“Branch” em uma linguagem de programação é como as “declarações IF”. Uma declaração IF tem dois ramos: T arruda e falsa .

Portanto, na cobertura de ramo (também chamada de cobertura de decisão), validamos se cada ramo é executado pelo menos uma vez.

No caso de uma “declaração IF”, haverá duas condições de teste:

• Um para validar o verdadeiro ramo e,
• Outro para validar o ramo falso.

Portanto, em teoria, a cobertura de ramificação é um método de teste que, quando executado, garante que cada ramificação de cada ponto de decisão seja executada.

# 3) Cobertura do caminho

A cobertura de caminho testa todos os caminhos do programa. Esta é uma técnica abrangente que garante que todos os caminhos do programa sejam percorridos pelo menos uma vez. A cobertura de caminho é ainda mais poderosa do que a cobertura de ramificação. Esta técnica é útil para testar programas complexos.

Vamos dar um exemplo simples para entender todas essas técnicas de teste de caixa branca.

dfs e bfs c ++

Verifique também=> Diferentes tipos de teste

Exemplo de teste de caixa branca

Considere o pseudocódigo simples abaixo:

Pra Cobertura de Declaração - precisaríamos apenas de um caso de teste para verificar todas as linhas do código.

Que significa:

Se eu considerar TestCase_01 para ser (A = 40 e B = 70), então todas as linhas de código serão executadas.

Agora surge a pergunta:

1. Isso é suficiente?
2. E se eu considerar meu caso de teste como A = 33 e B = 45?

Como a cobertura da instrução cobrirá apenas o lado verdadeiro, para o pseudocódigo, apenas um caso de teste NÃO seria suficiente para testá-lo. Como testador, devemos considerar os casos negativos também.

Portanto, para cobertura máxima, precisamos considerar ' Cobertura de filial ' , que avaliará as condições “FALSAS”.

No mundo real, você pode adicionar declarações apropriadas quando a condição falhar.

Então agora o pseudocódigo se torna:

Visto que a cobertura de declaração não é suficiente para testar todo o pseudocódigo, exigiríamos cobertura de Branch para garantir cobertura máxima .

Portanto, para a cobertura de Branch, exigiríamos dois casos de teste para concluir o teste desse pseudocódigo.

TestCase_01 : A = 33, B = 45

TestCase_02 : A = 25, B = 30

Com isso, podemos ver que cada linha do código é executada pelo menos uma vez.

Aqui estão as conclusões derivadas até agora:

• A cobertura de filial garante mais cobertura do que a cobertura de declaração.
• A cobertura de filial é mais poderosa do que a cobertura de declaração.
• 100% de cobertura de Branch em si significa 100% de cobertura de instrução.
• Porém, 100% de cobertura de declaração não garante 100% de cobertura de filial.

Agora vamos passar para Cobertura do caminho:

Conforme dito anteriormente, a cobertura de caminho é usada para testar os trechos de código complexos, que basicamente envolvem instruções de loop ou combinação de loops e instruções de decisão.

Considere este pseudocódigo:

Agora, para garantir a cobertura máxima, precisaríamos de 4 casos de teste.

Quão? Simplesmente - existem 2 declarações de decisão, portanto, para cada declaração de decisão, precisaríamos de dois ramos para testar. Um para verdadeiro e outro para a condição falsa. Portanto, para 2 declarações de decisão, exigiríamos 2 casos de teste para testar o lado verdadeiro e 2 casos de teste para testar o lado falso, o que perfaz um total de 4 casos de teste.

Para simplificar, vamos considerar o fluxograma abaixo do pseudocódigo que temos:

Para ter a cobertura total, precisaríamos dos seguintes casos de teste:

TestCase_01: A = 50, B = 60

TestCase_02 : A = 55, B = 40

TestCase_03: A = 40, B = 65

TestCase_04: A = 30, B = 30

Portanto, o caminho percorrido será:

Linha Vermelha - TestCase_01 = (A = 50, B = 60)

Linha Azul = TestCase_02 = (A = 55, B = 40)

Linha laranja = TestCase_03 = (A = 40, B = 65)

Linha Verde = TestCase_04 = (A = 30, B = 30)

******************
= >> Contate-Nos para sugerir sua lista aqui
*****************

Ferramentas de teste de caixa branca

Dada abaixo está uma lista das principais ferramentas de teste da caixa branca.

# 1) Veracode

As ferramentas de teste de caixa branca da Veracode irão ajudá-lo a identificar e resolver as falhas de software de forma rápida e fácil a um custo reduzido. Suporta várias linguagens de aplicação como .NET, C ++, JAVA etc e também permite que você teste a segurança de aplicações desktop, web e móveis. Ainda assim, existem vários outros benefícios da ferramenta Veracode. Para obter informações detalhadas sobre as ferramentas de teste da caixa branca do Veracode, verifique o link abaixo.

Link do site: Veracode

# 2) EclEmma

EclEmma foi inicialmente projetado para execuções de teste e análise no ambiente de trabalho Eclipse. É considerada uma ferramenta gratuita de cobertura de código Java e também possui vários recursos. Para instalar ou saber mais sobre EclEmma, ​​verifique o link abaixo.

Link do site: EclEmma

# 3) RCUNIT

Uma estrutura usada para testar programas C é conhecida como RCUNIT. O RCUNIT pode ser usado de acordo com os termos da Licença do MIT. É de uso gratuito e para instalar ou saber mais sobre ele, consulte o link abaixo.

Link do site: RCUNIT

# 4) cfix

cfix é uma das estruturas de teste de unidade para C / C ++ que visa unicamente tornar o desenvolvimento de suítes de teste o mais simples e fácil possível. Enquanto isso, o cfix é tipicamente especializado para o modo NT Kernel e Win32. Para instalar e saber mais sobre o cfix, verifique o link abaixo

Link do site: cfix

# 5) Teste do Google

Googletest é a estrutura de teste C ++ do Google. Descoberta de teste, testes de morte, testes parametrizados por valor, falhas fatais e não fatais, geração de relatório de teste XML, etc. são alguns recursos do GoogleTest, mas também existem vários outros recursos. Linux, Windows, Symbian, Mac OS X são algumas plataformas em que o GoogleTest foi usado. A fim deBaixe, por favor, verifique o link abaixo.

Link para Download: Teste do Google

# 6) EMMA

Emma é uma ferramenta gratuita de cobertura de código JAVA fácil de usar. Inclui vários recursos e benefícios. Para baixar e saber mais sobre Emma, ​​verifique o link abaixo.

Link para Download: EMMA

# 7) NUnit

NUnit é uma estrutura de teste de unidade de código aberto fácil de usar que não requer nenhuma intervenção manual para julgar os resultados do teste. Suporta todas as linguagens .NET. Ele também oferece suporte a testes orientados por dados e testes executados em paralelo no NUnit. As versões anteriores do NUnit usavam a licença do NUnit, mas o NUnit 3 foi lançado sob a licença do MIT. Mas ambas as licenças permitem o uso gratuito sem quaisquer restrições. Para baixar e saber mais sobre o NUnit, verifique o link abaixo.

Link para Download: NUnit

# 8) CppUnit

CppUnit é uma estrutura de teste de unidade escrita em C ++ e é considerada a porta de JUnit. A saída de teste para CppUnit pode estar no formato XML ou de texto. Ele cria testes de unidade com sua própria classe e executa testes nas suítes de teste. Ele é licenciado pela LGPL. Para fazer download e saber mais sobre o CppUnit, verifique o link abaixo.

Link para Download: CppUnit

# 9) JUnit

JUnit é uma estrutura de teste de unidade simples e silenciosa que oferece suporte à automação de teste em linguagem de programação Java. Ele oferece suporte principalmente no Desenvolvimento Orientado a Testes e também fornece o relatório de cobertura de teste. Ele está licenciado sob a Licença Pública Eclipse. Para download gratuito e para saber mais sobre o JUnit, verifique o link abaixo.

Link para Download: JUnit

# 10) JsUnit

JsUnit é considerada a porta de JUnit para javascript. E é uma estrutura de teste de unidade de código aberto para suportar Javascript do lado do cliente. Ele está licenciado sob a GNU Public License 2.0, GNU Lesser Public License 2.1 e Mozilla Public License 1.1. Para baixar e saber mais sobre o JsUnit, verifique o link abaixo.

como posso ver um arquivo eps

Link para Download: JsUnit

Além disso, verifique todas as ferramentas que listamos em Análise de código estático aqui .

Sinta-se à vontade para sugerir ferramentas mais simples ou avançadas que você está usando para a técnica da caixa branca.

Conclusão

Confiar apenas no teste da caixa preta não é suficiente para a cobertura máxima do teste. Precisamos ter uma combinação de técnicas de teste de caixa preta e caixa branca para cobrir defeitos máximos .

Se feito corretamente, o teste da caixa branca certamente contribuirá para a qualidade do software. Também é bom que os testadores participem desse teste, pois ele pode fornecer a opinião mais 'imparcial' sobre o código. :)

Informe-nos se tiver alguma dúvida sobre os métodos discutidos neste artigo.

Leitura recomendada

• Principais diferenças entre o teste de caixa preta e o teste de caixa branca
• Teste da caixa preta: um tutorial aprofundado com exemplos e técnicas
• Teste Funcional Vs Teste Não Funcional
• Melhores ferramentas de teste de software 2021 (QA Test Automation Tools)
• Pensando fora da caixa ao testar o software!
• Guia de teste de portabilidade com exemplos práticos
• Teste Alfa e Teste Beta (um guia completo)
• Tipos de teste de software: diferentes tipos de teste com detalhes