A caixa branca é uma categoria de teste de software que se refere a métodos de teste do funcionamento da estrutura interna e da concepção do software. Contrasta com os testes de caixa negra, que são testes que não se preocupam com as operações internas do software, mas apenas testam os resultados externos do software.

Neste artigo, vamos explorar o tema dos testes de caixa branca: o que é, como funciona e que tipos de ferramentas de teste de software podem ajudar os testadores e os programadores a efectuar testes de caixa branca nos testes de software.

 

O que é um teste de caixa branca?

O teste da caixa branca é uma técnica de teste de software que envolve o teste da estrutura interna e da concepção de um software, por oposição aos resultados externos ou à experiência do utilizador final que são testados no teste da caixa preta.

O teste de caixa branca é um termo genérico que inclui muitos tipos diferentes de testes de software, incluindo testes unitários e testes de integração. Uma vez que os ensaios de caixa branca implicam o ensaio de código e de programação, a realização de ensaios de caixa branca implica normalmente alguns conhecimentos de programação informática.

Os testes de caixa branca em engenharia de software podem envolver o teste do código e do desenho interno do software para verificar o fluxo de entrada-saída e verificar o desenho, a usabilidade e a segurança do software.

Os testes de caixa branca permitem que os testadores inspeccionem o funcionamento interno do sistema ao mesmo tempo que verificam se as entradas resultam em saídas específicas e esperadas.

O teste de caixa branca é um passo essencial no teste de software porque é o único tipo de teste que considera o funcionamento do próprio código.

 

1. Quando e porque é que precisa de uma caixa branca

em testes e engenharia de software?

Os testes de caixa branca podem ser efectuados em diferentes fases do ciclo de testes para verificar o funcionamento do código interno e da estrutura.

Mais frequentemente, os testes de caixa branca ocorrem quando os programadores e os testadores efectuam testes unitários e, por vezes, durante os testes de integração.

Por definição, os testes unitários são considerados um tipo de teste de caixa branca, enquanto os testes de integração podem partilhar características tanto dos testes de caixa branca como dos testes de caixa preta, mas são geralmente considerados uma forma de teste de caixa preta.

Por outro lado, os testes de caixa branca também podem ser utilizados ad hoc para verificar o funcionamento interno de uma construção de software. Os testes de caixa branca são a forma mais económica de aumentar a cobertura dos testes, se tal for necessário, e são também uma forma fácil de verificar o funcionamento de secções específicas do código ou de testar áreas de uma construção de software que os testadores suspeitem estarem a ser pouco testadas.

As revisões formais do código, que são efectuadas com testes de caixa branca, também podem ser utilizadas para identificar falhas de segurança e outras vulnerabilidades. Do mesmo modo, se os elementos do código estiverem danificados, os testes de caixa branca podem ajudar os engenheiros de software a determinar onde está o erro.

 

2. Quando não é necessário efectuar testes de caixa branca

Na maioria dos casos, quando os engenheiros de software e os testadores estão a submeter uma nova construção de software ao ciclo de testes, é necessária alguma quantidade de testes de caixa branca para verificar o funcionamento interno do código.

O teste de unidades é um tipo de teste de caixa branca efectuado pelos programadores para verificar se as unidades individuais funcionam como esperado. Este tipo de teste inicial permite que os programadores identifiquem bugs e defeitos antes da realização de testes formais num ambiente de garantia de qualidade.

Após os testes unitários, realizam-se os testes de integração, os testes de sistema e os testes de aceitação do utilizador. Estas são geralmente consideradas formas de teste de caixa preta que não envolvem muitas técnicas de teste de caixa branca.

No entanto, em alguns casos, os testadores e os programadores podem utilizar testes de caixa branca durante estas fases para identificar defeitos específicos no código. Nesta fase, se não houver qualquer indicação de que existe algo de errado com o código e os testes da caixa negra passarem todos, muitas equipas de teste podem considerar que não há necessidade de efectuar mais testes da caixa branca.

 

3. Quem está envolvido nos testes de caixa branca?

Os testes de caixa branca são quase sempre efectuados por programadores de software e engenheiros de software. Isto deve-se ao facto de os testes de caixa branca exigirem um conhecimento pormenorizado do código informático e das técnicas de codificação, e de a maioria dos testadores de garantia de qualidade não possuir as competências técnicas necessárias para efectuar testes de caixa branca.

O teste de unidades, o principal tipo de teste de caixa branca, é sempre efectuado no ambiente de desenvolvimento pelos programadores. Os programadores podem também efectuar testes de caixa branca sempre que necessário, para verificar o funcionamento de diferentes elementos do código ou para verificar se os erros foram corrigidos correctamente.

 

As vantagens dos testes de caixa branca

Os testes de caixa branca permitem aos programadores e engenheiros de software testar mais aspectos do código do que os testes de caixa preta.

Enquanto os testes de caixa negra podem dizer-nos como funciona uma construção de software para os utilizadores finais, os testes de caixa branca podem dizer-nos mais sobre o funcionamento do código de software. Um código limpo e eficiente é essencial no desenvolvimento de software, especialmente se os programadores quiserem reutilizar o código mais tarde ou adicionar correcções e actualizações no futuro.

 

1. Maximizar a cobertura dos testes

 

Os testes de caixa branca podem ajudar os testadores a maximizar a cobertura dos testes. Testar a maior parte possível do código de software maximiza normalmente a possibilidade de detectar quaisquer erros ou falhas presentes no código, e o objectivo dos testes de caixa branca é normalmente testar a maior parte possível do código.

O teste de caixa preta, por outro lado, consiste simplesmente na execução de casos de teste que podem ou não oferecer uma ampla cobertura de código.

 

2. Encontrar erros e bugs ocultos

 

Uma das maiores vantagens dos testes de caixa branca é que, uma vez que os testes de caixa branca verificam a funcionalidade interna, é mais fácil para os programadores encontrarem erros e bugs que, de outra forma, poderiam estar escondidos no código.

Para além de identificar a presença de erros, é normalmente mais fácil localizar exactamente em que ponto da base de código se encontra um erro ao realizar testes de caixa branca, devido à natureza altamente específica deste tipo de técnica de teste.

 

3. Facilidade de automatização

 

É muito fácil automatizar os testes de caixa branca, especialmente quando se efectuam testes unitários. Os testes unitários requerem normalmente que os programadores testem pequenas partes de código individualmente para ver se funcionam como esperado. É muito fácil de automatizar, o que significa que é uma forma rápida e eficiente de testar software.

Esta é uma das razões pelas quais os testes unitários são efectuados antes de outros tipos de testes mais demorados.

 

4. Eficiência temporal

 

Os testes de caixa branca são eficientes em termos de tempo por várias razões.

Como já foi referido, é relativamente fácil automatizar a maioria dos tipos de testes de caixa branca, o que significa que é frequentemente mais rápido efectuar testes de caixa branca do que testes de caixa preta. Além disso, os testes de caixa branca facilitam aos programadores a localização dos erros que identificam no código, uma vez que os encontram enquanto testam o próprio código.

 

5. Qualidade do código

 

Os testes de caixa branca permitem que os programadores analisem novamente o código que escreveram e avaliem a sua qualidade e limpeza.

Analisar o código peça por peça dá aos programadores a oportunidade de remover secções de código desnecessárias e de limpar o código, o que facilita a reutilização e a edição de secções de código no futuro.

Pode também obrigar os programadores a reflectir sobre a forma como o código é implementado e se este será bem dimensionado no futuro.

 

Os desafios dos testes de caixa branca

Os testes de caixa branca não estão isentos de desafios. Existem algumas razões pelas quais algumas equipas de desenvolvimento podem considerar os testes de caixa branca mais difíceis de realizar do que os testes de caixa preta, bem como outras razões pelas quais podem ser vistos por algumas pessoas como menos importantes do que os testes de caixa preta.

 

1. Barreiras técnicas

 

Os testes de caixa branca implicam barreiras técnicas que não existem nos testes de caixa preta. Para efectuar testes de caixa branca, os testadores necessitam de ter conhecimentos sobre o funcionamento interno do sistema, o que, no caso dos testes de software, significa normalmente conhecimentos de programação.

É por este motivo que os testes de caixa branca são quase sempre efectuados por engenheiros e programadores de software e não por técnicos de controlo de qualidade, que raramente possuem as competências técnicas necessárias para realizar este tipo de testes.

 

2. Custo

 

Os testes de caixa branca podem ser mais dispendiosos do que os testes de caixa preta, devido ao carácter exaustivo deste tipo de testes.

Os programadores têm de despender muito tempo a escrever testes unitários intensivos e os testes de caixa branca não podem, muitas vezes, ser reutilizados noutras aplicações, o que significa que os testes de caixa branca têm, normalmente, um custo bastante elevado.

 

3. Exactidão

 

Os testes de caixa branca nem sempre são o método de teste de software mais exacto e, se as equipas de desenvolvimento se baseassem apenas nos testes de caixa branca, isso resultaria na perda de muitos erros e casos.

Os testes de caixa branca apenas validam características que já existem, enquanto os testes de caixa preta podem ser utilizados para testar características parcialmente implementadas ou identificar características que estão efectivamente em falta no software e que devem ser incluídas em iterações posteriores.

 

4. Âmbito de aplicação

 

Os testes de caixa branca normalmente não nos dizem muito sobre a experiência do utilizador ou o resultado final das funções incorporadas no software.

Embora os programadores possam utilizar os testes de caixa branca para verificar se o código está a funcionar como deveria, não podem concluir que o código de trabalho está a fornecer os resultados correctos aos utilizadores finais sem combinar os testes de caixa branca com os testes de caixa preta.

Isto significa que existem limitações no âmbito dos testes de caixa branca e no que estes nos podem dizer sobre o software.

 

As características dos testes de caixa branca

Os testes de caixa branca podem ser definidos por características específicas que os diferenciam de outras formas de teste, como os testes de caixa preta e de caixa cinzenta.

A maior parte destas características pode ser considerada do ponto de vista da sua diferença em relação às características dos testes de caixa negra e da forma como estas diferenciam os testes de caixa branca dos testes de caixa negra.

 

1. Capacidade de manutenção

 

Os testes de caixa branca conduzem a um maior nível de manutenção do seu código, simplificando o trabalho que a sua equipa tem de fazer no futuro.

Uma vez que existe um controlo constante do código e do que este faz com os dados, a sua manutenção é muito mais simples, uma vez que se compreende onde surgem os problemas e porquê. Isto também mantém o código mais simples para futuras actualizações, uma vez que não se desenvolvem correcções grandes e complexas para problemas simples e desconhecidos.

 

2. Flexibilidade

 

Os testes de caixa branca são efectuados em código que é suficientemente flexível para aceitar alterações com relativa rapidez. Código inflexível, como o que faz parte de um módulo ou integração de terceiros, impede que um testador de caixa branca faça alterações rápidas.

Concentrar-se em ter código que possa ser alterado assim que descobrir um problema torna os testes de caixa branca altamente adaptáveis e significa que os problemas de um programa são resolvidos muito mais cedo.

 

3. Modularidade

 

Os testes de caixa branca prosperam em código que tem um certo grau de modularidade, o que significa que os elementos separados do software têm uma distinção clara entre si.

Se um programa tiver um problema de “código esparguete” em que cada aspecto está ligado a outro, os testes de caixa branca tornam-se infinitamente mais complexos, uma vez que um testador tem de examinar todo o programa em vez de uma unidade específica.

 

4. Integração

 

Os testes de caixa branca são extremamente úteis para os testes de integração. Os testadores podem ver se uma função está a funcionar até ao momento em que sai do software em questão e se regressa do sistema integrado tão funcional como esperado.

Isto é altamente informativo e permite a uma organização saber se o problema é local ou faz parte da plataforma integrada.

 

O que é que testamos nos testes de caixa branca?

Os testes de caixa branca são utilizados para testar características do código que não podem ser verificadas por métodos de teste de caixa preta. Isto pode significar testar o funcionamento do próprio código, o que permite aos programadores compreender a causa e o efeito de diferentes aspectos do código.

Os programadores utilizam os testes de caixa branca para testar falhas de segurança, instruções e funções, resultados e caminhos no código.

 

1. Furos de segurança internos

 

Os testes de caixa branca podem ser utilizados para procurar lacunas de segurança e vulnerabilidades no código que os piratas informáticos e os cibercriminosos possam aproveitar no futuro.

Os testes de caixa branca podem ser utilizados para verificar se as melhores práticas de segurança foram seguidas durante a fase de desenvolvimento e para procurar vulnerabilidades de segurança que possam ser reparadas antes de o código passar a outros testes.

 

2. Caminhos nos processos de codificação

 

Os testes de caixa branca permitem que os programadores testem os caminhos que ligam diferentes elementos do código. Os programadores não estão apenas a testar a lógica do código, mas também podem procurar a estrutura e a higiene do código.

Um código bom e limpo não tem linhas desnecessárias ou elementos quebrados que não funcionam como esperado, mesmo que os resultados externos dos testes de caixa preta sejam os esperados.

 

3. Resultados esperados

 

Os testes de caixa branca também podem testar os resultados esperados do código da mesma forma que os testes de caixa preta, embora os testadores o façam considerando o código e não utilizando a aplicação como os testadores podem fazer nos testes de caixa preta.

Os programadores testam os resultados esperados, verificando as entradas uma a uma e verificando se o resultado está de acordo com as expectativas.

 

4. Declarações, objectos e funções

 

Através da aplicação de técnicas de teste de caixa branca, os programadores de software podem garantir que as instruções, os objectos e as funções do código se comportam de forma lógica e produzem os resultados esperados.

 

5. Funcionalidade dos ciclos condicionais

 

Os testes de caixa branca também podem ser utilizados para verificar a funcionalidade dos loops condicionais, incluindo loops simples, concatenados e aninhados. Os programadores verificarão se estes loops são eficientes, se cumprem os requisitos da lógica condicional e se tratam correctamente as variáveis locais e globais.

 

Esclarecer alguma confusão:

Testes de caixa branca vs caixa preta vs caixa cinzenta

O teste da caixa branca, o teste da caixa preta e o teste da caixa cinzenta são termos que os testadores de software utilizam para se referirem a diferentes categorias de testes ou a diferentes métodos de teste.

Uma visão moderna destas distinções de testes é que as linhas traçadas entre os diferentes tipos de testes de caixa estão a tornar-se mais ténues, uma vez que os diferentes tipos de testes combinam frequentemente elementos de testes de caixa branca e preta e derivam testes de documentos a vários níveis de abstracção.

No entanto, continuam a existir distinções importantes entre estas formas de teste.

 

1. O que é o teste da caixa negra?

O teste da caixa negra é uma forma de teste de software em que a funcionalidade do software é verificada por testadores que não têm conhecimento da estrutura interna do código ou de como implementar o código a um nível mais técnico.

Os testes de caixa negra apenas testam os resultados externos do software ou, por outras palavras, testam o que o utilizador final irá sentir ao utilizar o software.

Os testes de caixa negra são também conhecidos como testes comportamentais, porque testam o comportamento do software em determinadas condições.

Os testadores podem utilizar os testes de caixa negra para avaliar o modo como as diferentes funções do software se comportam e compará-las com as expectativas para se certificarem de que o software satisfaz os requisitos dos utilizadores. Os testes de caixa negra são utilizados nos testes de sistemas e nos testes de aceitação para verificar diferentes funções e verificar se o sistema funciona como esperado quando funciona como um todo.

Ao realizar testes de caixa negra, os utilizadores escrevem casos de teste para verificar diferentes elementos individualmente. Uma vez que os testes de caixa negra não requerem as mesmas competências técnicas que os testes de caixa branca, estes são normalmente efectuados por testadores num ambiente de garantia de qualidade e não por programadores.

A automatização dos testes de caixa negra é normalmente mais fácil de automatizar quando comparada com os testes de caixa branca, utilizando ferramentas de automatização de ponta a ponta como o ZAPTEST.

 

Quais são as diferenças entre testes de caixa branca e caixa preta?

A principal diferença entre os testes de caixa preta e de caixa branca é o que está a ser testado.

Os testes de caixa preta consistem em testar os resultados externos da construção do software, ao passo que os testes de caixa branca consistem em testar o que se passa por detrás do capô.

 

Algumas das principais diferenças entre os testes de caixa preta e de caixa branca são:

 

Objectivo

O objectivo dos testes de caixa negra é verificar se o sistema funciona como esperado para o utilizador final, enquanto o objectivo dos testes de caixa branca é verificar a qualidade e a integridade do código do software.

Por exemplo, nos testes de caixa negra de um jogo de vídeo, um utilizador final pode experimentar o jogo e avaliar a sua experiência, enquanto os testes de caixa branca do mesmo projecto garantem que a introdução de dados específicos leva a que a personagem realize a acção correcta.

 

Processo

Os processos utilizados nos testes de caixa branca e preta são muito diferentes. Os testes de caixa branca são muito mais fáceis de automatizar do que os testes de caixa preta e, normalmente, os testes de caixa preta devem ser automatizados com a ajuda de ferramentas de automatização de software.

Por exemplo, quando se testa uma base de dados, um teste de caixa branca envolve a automatização da introdução de dados para verificar se todos os resultados estão correctos, enquanto que os testes de caixa preta envolvem utilizadores que replicam processos manuais e elaboram relatórios sobre os mesmos sem a utilização de um sistema de automatização.

 

Testers

Os testes de caixa preta são quase sempre efectuados num ambiente de garantia de qualidade por profissionais de teste de software, enquanto os testes de caixa branca são efectuados por programadores e engenheiros de software que possuem um conhecimento técnico mais detalhado do código-fonte.

 

Técnicas

Os testes de caixa negra utilizam várias técnicas, como a partição de equivalência, a análise de valor-limite e o teste de tabela de decisão. Os testes de caixa branca utilizam técnicas como cobertura de decisão, cobertura de condição e cobertura de declaração.

 

Operações

As metodologias de ensaio da caixa negra são adequadas para operações de ensaio de nível superior, como os ensaios de sistemas e os ensaios de aceitação, enquanto os ensaios da caixa branca são mais adequados para operações de nível inferior, como os ensaios unitários e os ensaios de integração.

Por este motivo, os testes de caixa branca são normalmente efectuados antes da maioria das formas de testes de caixa preta.

 

2. O que é o teste da caixa cinzenta?

O teste da caixa cinzenta é uma técnica de teste de software utilizada para testar produtos e aplicações de software por testadores que podem ter um conhecimento parcial da estrutura interna da aplicação, mas não um conhecimento completo da mesma.

Os testes de caixa cinzenta podem combinar elementos de testes de caixa preta e de caixa branca para permitir que os programadores e os testadores identifiquem defeitos no código e localizem erros específicos do contexto.

Os testes de caixa cinzenta combinam características dos testes de caixa negra e dos testes de caixa branca. Os testadores devem ter algum conhecimento do funcionamento interno do sistema, como nos testes de caixa branca, mas utilizam esse conhecimento para criar casos de teste e executá-los ao nível da funcionalidade, como acontece nos testes de caixa preta.

Os testes da caixa cinzenta oferecem muitas das vantagens dos testes da caixa preta e da caixa branca, sendo também relativamente eficientes em termos de tempo e flexíveis.

 

Quais são as diferenças entre testes de caixa branca e caixa cinzenta?

Uma vez que os testes de caixa cinzenta oferecem algumas das mesmas funcionalidades que os testes de caixa preta, existem algumas diferenças importantes entre os testes de caixa cinzenta e os testes de caixa branca, embora talvez não tantas como nos testes de caixa preta.

 

Algumas das maiores diferenças entre os testes de caixa cinzenta e os testes de caixa branca são:

 

Conhecimentos estruturais

 

Nos testes de caixa branca, a concepção interna e a estrutura do código devem ser totalmente conhecidas pela pessoa que efectua o teste. Nos testes de caixa cinzenta, a estrutura interna do código é normalmente conhecida apenas parcialmente.

 

Pessoas envolvidas

 

Os testes de caixa branca são quase exclusivamente realizados por programadores de software e engenheiros de software, enquanto os testes de caixa cinzenta podem ser realizados por utilizadores finais, testadores e programadores.

 

Eficiência

 

Os testes de caixa branca são considerados o tipo de teste de software mais moroso, enquanto os testes de caixa cinzenta aproveitam algumas das eficiências dos testes de caixa preta para reduzir o tempo necessário para efectuar os testes.

 

Funcionamento

 

Nos testes de caixa branca, os programadores limitam-se a escrever código para implementar testes de caixa branca e a executar esse código. Nos testes da caixa cinzenta, tal como nos testes da caixa negra, os testadores efectuam testes funcionais para avaliar o funcionamento externo do sistema.

 

Cobertura

 

Os testes de caixa branca são o tipo de teste mais exaustivo, enquanto a cobertura dos testes de caixa cinzenta pode variar consoante o tipo de casos de teste executados se baseie em código ou GUI.

 

Conclusão:

Caixa branca vs. caixa preta Testes de caixa branca vs. caixa preta

O teste da caixa branca, o teste da caixa preta e o teste da caixa cinzenta são termos utilizados para designar diferentes técnicas de teste de software. Em termos gerais, cada tipo de teste pode ser definido com base no grau de conhecimento que os testadores devem ter sobre a base de código e a implementação do código:

 

1. Testes de caixa negra:

A estrutura interna do código é desconhecida.

 

2. Testes de caixa branca:

A estrutura interna do código é conhecida.

 

3. Testes de caixa cinzenta:

A estrutura interna do código é parcialmente conhecida.

 

Durante os testes de software, os três tipos de testes são importantes para verificar a função e a integridade do software. Enquanto os testes de caixa branca nos informam mais sobre a estrutura subjacente do código, os testes de caixa cinzenta e os testes de caixa negra podem verificar o funcionamento do sistema e se este satisfaz os requisitos do utilizador final.

Talvez as maiores diferenças entre estes três tipos de teste estejam relacionadas com quem realiza cada tipo de teste, com os requisitos do próprio teste e com o que este implica.

Os testes de caixa branca têm a maior barreira à entrada, porque são efectuados por programadores com um conhecimento detalhado da própria base de código e porque são o tipo de testes mais moroso e frequentemente mais dispendioso.

Em contrapartida, os testes de caixa negra são os mais fáceis de efectuar e podem ser realizados por testadores sem qualquer conhecimento do código subjacente.

 

Tipos de testes de caixa branca

Existem muitos tipos diferentes de testes de caixa branca, cada um dos quais pode ser utilizado para testar aspectos ligeiramente diferentes da estrutura interna do código.

Seguem-se alguns dos tipos mais comuns de testes de caixa branca utilizados actualmente.

 

1. Teste de trajectória

 

O teste de percurso é um tipo de teste de caixa branca baseado na estrutura de controlo de um programa. Os programadores utilizam a estrutura de controlo para criar um gráfico de fluxo de controlo e testar diferentes caminhos no gráfico.

O teste de percurso é um tipo de teste que depende da estrutura de controlo do programa, o que significa que exige que os testadores tenham um conhecimento profundo desta estrutura.

Por exemplo, se um sistema é suposto contactar os clientes com mensagens definidas em determinados pontos do funil de vendas, o teste de percurso implica garantir que segue os passos correctos em função das condições definidas pelos dados.

 

2. Ensaio de laços

 

O teste de loops é um dos tipos mais importantes de teste de caixa branca que testa loops dentro do código do programa. Os loops são implementados em algoritmos dentro do código e os testes de loop verificam se esses loops são válidos.

Os testes de ciclos podem avaliar se existem vulnerabilidades em ciclos específicos e destacar áreas em que os programadores podem ter de corrigir o código para garantir que o ciclo está a funcionar como deveria.

Um exemplo de um teste de ciclo é o seguimento do ciclo com um conjunto específico de pontos de dados que levam o ciclo a continuar, como a recusa de aceitar alguns termos e condições, antes de introduzir um valor que quebra especificamente o ciclo. Se o ciclo se comportar como esperado, o teste é bem sucedido.

 

3. Testes condicionais

 

O teste condicional é um tipo de teste de caixa branca que verifica se as condições lógicas dos valores no código são verdadeiras ou falsas.

O teste condicional é uma forma importante de teste de caixa branca que diz aos programadores se o código é lógico e cumpre os requisitos da lógica de programação.

Um exemplo de teste condicional é numa plataforma de contabilidade. A introdução de uma série de despesas e rendimentos deve resultar nos totais correctos, com o software a fornecer resultados precisos ao longo de um teste bem sucedido.

 

4. Testes unitários

 

O teste de unidades é uma fase importante do teste de software em que os programadores testam componentes e módulos individuais e verificam se funcionam como esperado antes de integrarem diferentes unidades.

Os engenheiros de software utilizam métodos de teste de caixa branca nos testes unitários para testar pequenas partes de código de cada vez. Isto facilita a identificação de bugs e erros quando estes ocorrem durante os testes.

Um exemplo de testes unitários é o início do desenvolvimento, quando uma empresa cria um simples botão num sítio Web que leva o utilizador para outra página. Se a unidade funcionar como esperado, então é bem sucedida, com os programadores a fazerem alterações até que isso aconteça.

 

5. Testes de mutação

 

O teste de mutações é um tipo de teste que analisa alterações e mutações. Nos testes de mutação, os programadores efectuam pequenas modificações no código-fonte para ver se isso pode revelar erros no código.

Se o caso de teste passar, isso indica que há algum problema com o código, porque não deveria passar depois de as alterações terem sido efectuadas. Idealmente, nos testes de mutação, todos os casos de teste falharão.

Um exemplo de teste de mutação é a aprendizagem automática. Os programas de aprendizagem automática “sofrem mutações” automaticamente em função de novas informações, pelo que testar estes programas de forma consistente para o padrão de “mutação” informa os programadores sobre se o software funciona como esperado.

 

6. Ensaios de integração

 

O teste de integração é uma fase importante do teste de software durante a qual os testadores verificam se diferentes módulos funcionam correctamente quando integrados com outros módulos.

As técnicas de teste de caixa branca são utilizadas durante os testes de integração para verificar se o código funciona mesmo quando vários módulos – que muitas vezes foram codificados por diferentes programadores – trabalham em conjunto.

Quando uma base de dados obtém informações de uma fonte online, por exemplo, os testes de integração garantem que os dados obtidos são exactos e actualizados a um ritmo razoavelmente consistente.

 

7. Testes de penetração

 

Os testes de penetração são um tipo de teste de caixa branca que pode ser utilizado para simular ciberataques específicos ao sistema.

Nos testes de penetração, os testadores têm acesso a dados completos da rede e do sistema, como palavras-passe e mapas da rede. Em seguida, tentam aceder ou destruir dados dentro do sistema, tentando o maior número possível de caminhos de ataque.

Os testes de penetração são um aspecto importante dos testes de segurança que devem ser efectuados em todas as construções de software.

Uma plataforma de RH, por exemplo, efectuará testes de penetração e procurará vulnerabilidades no código para se certificar de que a plataforma é suficientemente segura para guardar os dados dos empregados.

 

Técnicas de teste de caixa branca

Existem muitas técnicas diferentes de teste de caixa branca que podem ser utilizadas para efectuar os testes de caixa branca acima referidos. Como é sempre o caso, diferentes técnicas são mais adequadas para testar diferentes aspectos do código, mas todas as técnicas de caixa branca listadas abaixo são importantes.

 

1. Cobertura da declaração

 

Uma das características que definem os testes de caixa branca é o facto de os testadores deverem tentar cobrir o máximo possível do código-fonte quando efectuam testes de caixa branca.

A cobertura do código é uma forte medida disso, e a cobertura de declarações é uma dessas técnicas que os testadores de caixa branca podem usar para aumentar a cobertura de declarações dentro do código.

A cobertura de instruções é uma métrica que mede o número de instruções executadas dividido pelo número total de instruções e multiplicado por 100. Os testadores de caixa branca devem ter como objectivo uma cobertura de declaração elevada.

 

2. Cobertura dos ramos

 

A cobertura de ramos, tal como a cobertura de instruções, reflecte a amplitude da cobertura de elementos específicos do código nos testes de caixa branca. As ramificações são equivalentes às declarações “IF” na lógica, em que o código se ramifica em opções verdadeiras e falsas que afectam o resultado da operação.

Ao utilizar técnicas de cobertura de ramos, os testadores de caixa branca verificam se cada ramo é processado pelo menos uma vez e validam se ambos os ramos funcionam correctamente.

 

3. Cobertura da via

 

As técnicas de cobertura de caminhos avaliam os caminhos dentro de uma aplicação de software. Maximizar a cobertura do caminho de teste significa garantir que todos os caminhos dentro do programa sejam explorados pelo menos uma vez. É um tipo de técnica de teste semelhante à cobertura de ramos, mas é considerada mais completa e eficaz.

Os testes de cobertura de trajectória são geralmente considerados mais adequados para testar aplicações completas do que compilações parciais.

 

4. Cobertura da decisão

 

A cobertura de decisão é uma das técnicas de caixa branca mais importantes porque fornece dados sobre os resultados verdadeiros e falsos das expressões booleanas no código-fonte.

Os testes de cobertura de decisão validam o código-fonte garantindo que cada marca de cada decisão potencial é percorrida pelo menos uma vez durante o teste.

Os pontos de decisão incluem todas as ocasiões em que existe a possibilidade de dois ou mais resultados diferentes.

 

5. Cobertura das condições

 

A cobertura de condições é também conhecida como cobertura de expressão. Esta técnica de caixa branca avalia as sub-variáveis em declarações condicionais dentro do código para verificar o resultado de cada condição lógica.

Este tipo de teste considera apenas expressões com operandos lógicos, enquanto que os testes de cobertura de decisão e de cobertura de ramificação são utilizados para garantir outras operações lógicas.

 

6. Cobertura de condições múltiplas

 

Nos testes de cobertura de condições múltiplas, os testadores verificam diferentes combinações de condições e avaliam a decisão que o código toma para cada combinação.

Pode haver muitos casos de teste diferentes para testes de cobertura de condições múltiplas devido ao grande número de combinações de condições que existem, pelo que este tipo de teste é frequentemente muito moroso.

 

7. Cobertura da máquina de estados finitos

 

A cobertura da máquina de estados finitos é um tipo importante de teste, mas também uma das formas mais difíceis de obter uma cobertura de código elevada nos testes de caixa branca. Funciona com base na funcionalidade do projecto e exige que os programadores contem o número de vezes que um estado é visitado ou transita durante o processo de teste, bem como o número de sequências que cada sistema de estados finitos contém.

 

8. Ensaio do fluxo de controlo

 

O teste do fluxo de controlo é uma técnica de teste de caixa branca que procura estabelecer a ordem de execução do programa utilizando uma estrutura de controlo simples.

Os programadores constroem casos de teste de fluxo de controlo escolhendo uma secção específica do programa e construindo um caminho de teste. O teste do fluxo de controlo é normalmente utilizado nos testes unitários.

 

O ciclo de vida dos testes de caixa branca

no desenvolvimento de software

O teste de caixa branca é uma etapa importante no ciclo de vida do desenvolvimento de software, embora não tenha um “lugar” específico no ciclo.

Os programadores podem efectuar testes de caixa branca sempre que precisarem de verificar o funcionamento do código e alguns programadores podem ser mais meticulosos do que outros na verificação do código recentemente escrito para se certificarem de que está limpo e sem linhas desnecessárias.

No entanto, os testes de caixa branca são mais frequentemente efectuados durante os testes unitários e os testes de integração. Tanto os testes unitários como os testes de integração são efectuados durante a fase de desenvolvimento pelos programadores.

Ocorrem antes dos testes funcionais, como os testes de sistema e os testes de aceitação, e dão aos programadores a oportunidade de identificar, localizar e corrigir os principais erros no início da fase de testes, antes de entregarem o produto à equipa de garantia de qualidade.

 

Testes de caixa branca manuais ou automatizados?

Tal como noutros tipos de testes de software, é possível automatizar os testes de caixa branca. Pode ser manual ou automatizado, embora na maioria dos casos seja mais fácil automatizar os testes de caixa branca do que os testes de caixa preta.

Como os testes de caixa branca são um tipo de teste que consome muito tempo, a automatização está a tornar-se cada vez mais popular entre as equipas de software.

 

Teste manual de caixa branca: benefícios, desafios e processos

 

Os testes manuais de caixa branca significam a realização de testes de caixa branca manualmente e exigem que os programadores tenham as competências e o tempo necessários para escrever casos de teste individuais para testar todas as linhas de código possíveis numa construção de software. Isto pode levar muito tempo, mas também resulta em resultados de testes e resultados mais completos.

 

Algumas das vantagens de efectuar testes de caixa branca manualmente incluem

 

1. Profundidade

Os testes manuais permitem aos testadores explorar o código do software com maior profundidade do que os testes automatizados, se assim o desejarem, por exemplo, lendo todo o código-fonte de uma aplicação em vez de se limitarem a automatizar tarefas que tocam a funcionalidade superficial.

 

2. Localização do erro

Os testes manuais facilitam a localização de erros e defeitos porque os programadores devem ser capazes de identificar exactamente a linha de código em que o erro está presente.

Por exemplo, ao ver que uma imagem não está a carregar, examinar o código em busca de linhas que envolvam o carregamento de imagens reduz significativamente a causa.

 

3. Velocidade

Os testes manuais normalmente demoram mais tempo do que os testes automatizados, mas se os programadores quiserem efectuar apenas um ou dois testes rápidos, é provavelmente mais rápido realizá-los manualmente do que configurar a automatização.

Por exemplo, os testes unitários envolvem a análise de uma funcionalidade e a verificação do seu funcionamento, em vez da recolha de grandes quantidades de dados através da automatização do processo. No entanto, existem também desvantagens nos testes manuais de caixa branca.

 

Alguns dos desafios dos testes manuais de caixa branca incluem:

 

1. Precisão

Os testes manuais podem permitir que os programadores cubram uma vasta gama de códigos, mas os testadores humanos são sempre mais propensos a erros e enganos do que os programas informáticos, o que significa que os testes manuais são frequentemente considerados menos exactos do que os testes automatizados.

 

2. Tempo

Os testes manuais demoram mais tempo do que os testes automatizados e os testes manuais de caixa branca são dos que consomem mais tempo. Este facto aumenta o tempo de execução e pode dificultar o cumprimento de prazos de desenvolvimento apertados.

 

3. Custo

Devido à quantidade de mão-de-obra e recursos envolvidos nos testes manuais de caixa branca, estes são frequentemente mais dispendiosos para as equipas de desenvolvimento do que os testes automatizados, que normalmente requerem menos programadores e menos tempo.

 

4. Escalabilidade

O teste manual só é realmente adequado para testar pequenas aplicações ou componentes individuais de aplicações maiores. Para aplicações maiores, como uma base de dados alojada na nuvem com milhares de entradas por minuto, os testes automatizados são muito preferidos como método de simulação de cargas padrão.

 

Testes automatizados de caixa branca: vantagens,

desafios e processos

A tecnologia de automatização está a facilitar a automatização de aspectos dos testes de software todos os dias. A evolução da indústria para a hiperautomatização deve-se, em parte, à eficiência e à poupança de custos que a automatização oferece às equipas de desenvolvimento, que se sentem sempre apertadas.

A caixa branca é um dos tipos de testes mais apropriados e adequados para a automatização porque é relativamente fácil de automatizar e as poupanças de tempo e de custos da automatização dos testes de caixa branca podem ser significativas.

Os testes automatizados de caixa branca podem implicar que os programadores escrevam eles próprios scripts de teste, ou o processo pode ser acelerado com a utilização de ferramentas de pilha completa como o ZAPTEST, que fornece tecnologia de ponta para testes de software.

 

Algumas das vantagens da automatização dos testes de caixa branca incluem:

 

1. Precisão

Os testes efectuados por computador eliminam o risco de erros porque os computadores não se cansam nem cometem erros.

 

2. Tempo

Os testes automatizados de caixa branca são significativamente mais rápidos do que os testes manuais de caixa branca e libertam tempo que os programadores podem gastar noutras tarefas, como a correcção de erros ou a elaboração de correcções de actualização.

 

3. Escala

Os testes automatizados são muito mais eficazes do que os testes manuais, pelo que, se a sua aplicação de software crescer ou se pretender efectuar testes em grande escala de uma só vez, a automatização é a melhor opção.

Por exemplo, aumentar a entrada de dados implica solicitar mais entradas na automatização, em comparação com a contratação de mais pessoal nos testes manuais.

 

4. Custo

O custo dos testes automatizados é geralmente, uma vez totalizado, inferior ao custo dos testes manuais, devido ao número de horas de trabalho poupadas pela automatização. O ROI de 10x do ZAPTEST demonstra como a automatização pode poupar dinheiro aos programadores e levar a maiores retornos. No entanto, a automatização tem os seus inconvenientes.

 

Alguns dos desafios da automatização dos testes de caixa branca incluem:

 

1. Controlo de erros

A automatização nem sempre facilita a localização de erros no código, dependendo da forma como os programadores automatizam os testes ou das ferramentas de teste utilizadas, especialmente quando comparada com os testes manuais de caixa branca, em que os testadores podem ver o código que está a ser executado sempre que surge um erro.

 

2. Competências

Nem todos os programadores sabem como automatizar testes ou como utilizar ferramentas de teste automatizadas, pelo que a mudança para a automatização pode exigir algum investimento na formação de competências importantes, como a codificação na linguagem da plataforma de teste específica e a utilização de competências de análise de dados para compreender a causa dos problemas num teste de caixa branca.

 

Conclusão: Teste manual de caixa branca

ou automatização de testes de caixa branca?

De um modo geral, os testes de caixa branca na engenharia de software são um dos tipos de testes mais adequados para se adaptarem aos testes automatizados, em grande parte devido à natureza morosa e complexa dos testes manuais de caixa branca.

Os testes automatizados de caixa branca são mais rápidos, mais baratos, mais eficientes e mais precisos do que os testes manuais, especialmente quando se trabalha com aplicações maiores.

Sempre que possível, os programadores de software devem automatizar os testes de caixa branca nos testes de software para aumentar a fiabilidade dos testes e cobrir uma área maior de aplicações maiores através de testes do que é praticamente possível ao realizar os testes manualmente. Isto deve-se aos custos e conhecimentos significativos necessários quando se efectuam testes de caixa branca com métodos exclusivamente manuais.

 

O que é necessário para começar

testes de caixa branca?

Antes de iniciar o teste de caixa branca, certifique-se de que tem tudo o que precisa para começar. Dependendo do facto de estar a realizar testes de caixa branca manuais ou automatizados, não são necessários muitos recursos para além de tempo e dinheiro.

No entanto, terá de garantir que a sua equipa possui os conhecimentos e as ferramentas adequadas para efectuar correctamente os testes de caixa branca.

 

1. Compreensão do código-fonte

 

Os testes de caixa branca são testes efectuados por programadores e engenheiros de software com pleno conhecimento do código-fonte e da estrutura interna do software.

Se for um verificador de garantia de qualidade sem este conhecimento, terá de passar o software a outra pessoa antes de poder iniciar o teste de caixa branca.

 

2. Casos de teste

 

É necessário escrever casos de teste antes de executar o teste de caixa branca. Os casos de teste são conjuntos individuais de instruções que descrevem acções que os testadores ou os programadores podem realizar para testar as funções e o funcionamento de um sistema.

Nos testes de caixa branca, os casos de teste são concebidos por pessoas com um conhecimento completo da estrutura interna do sistema e criados para verificar se este funciona como deveria.

 

3. Ferramentas de teste de caixa branca

 

Existem muitas ferramentas disponíveis para testes de caixa branca que permitem o acesso ao código-fonte e aos documentos de concepção, para além de completarem a automatização dos testes. Estes também estão disponíveis em vários níveis de preços para os utilizadores, tais como as versões ZAPTEST FREE e ZAPTEST ENTERPRISE que proporcionam maior flexibilidade.

Escolha as ferramentas que pretende utilizar antes de começar a testar, com ênfase na garantia de que têm a funcionalidade correcta, como o funcionamento entre plataformas e a tecnologia de visão por computador, para que veja o que os testes automatizados vêem.

Certifique-se de que todos os programadores e engenheiros envolvidos nos testes sabem como e quando os utilizar.

 

O processo de teste de caixa branca

Os testes de caixa branca envolvem muito mais conhecimento do funcionamento de um sistema do que os testes de caixa preta, e algumas das etapas dos testes de caixa branca são um pouco diferentes.

Os testadores de caixa branca devem primeiro identificar as características ou componentes do sistema que querem verificar antes de traçar possíveis caminhos para testar e escrever casos de teste para executar.

O processo de teste da caixa branca também pode ser diferente consoante a técnica de teste da caixa branca utilizada. Siga as etapas abaixo para descobrir como realizar testes de caixa branca e maximizar a cobertura do caminho.

 

Etapa 1: Identificar as características a serem testadas

 

Antes de efectuar um teste de caixa branca, considere exactamente o que pretende testar e como o vai fazer. Normalmente, isto implica concentrar-se num pequeno conjunto de funções ou características e criar um conjunto de casos de teste apenas para as testar.

Este passo será repetido várias vezes para diferentes áreas do sistema para maximizar a cobertura dos testes, mas é importante dividir as diferentes áreas em testes individuais.

Quanto mais restrito for o seu foco, mais fiáveis e precisos poderão ser os seus testes.

 

Passo 2: Traçar todos os caminhos possíveis num gráfico de fluxo

 

Uma parte significativa do seu trabalho de preparação para os testes de caixa branca consiste em traçar todos os caminhos possíveis que precisa de testar num fluxograma.

Este passo pode ajudá-lo a maximizar a cobertura do caminho e a garantir que está a verificar todos os caminhos possíveis em cada caso de teste que cria. Desenhe um fluxograma que abranja todos os caminhos possíveis para cada característica ou componente que está a testar, por exemplo, delineando vários caminhos que surgem quando são introduzidos valores diferentes.

 

Passo 3: Identificar todos os caminhos possíveis

 

Observe o seu fluxograma e identifique todos os caminhos possíveis que os utilizadores podem seguir, começando no primeiro passo do seu fluxograma e terminando no último passo.

Quanto mais ramos e decisões existirem no seu fluxograma, mais caminhos únicos existirão. Compreender quantos caminhos únicos possíveis existem pode ajudá-lo a certificar-se de que os seus casos de teste abrangem cada possibilidade.

 

Passo 4: Criar casos de teste

 

A próxima etapa do teste de caixa branca é escrever casos de teste que verifiquem todos os caminhos que identificou acima.

É importante certificar-se de que os seus casos de teste abrangem todos os caminhos possíveis e definem claramente as acções que os testadores ou os programadores devem realizar para executar cada caso de teste.

Para cada caso de teste, inclua um ID e um nome do caso de teste, juntamente com uma breve descrição e os resultados esperados de cada teste.

 

Etapa 5: Executar casos de teste

 

É agora altura de executar os casos de teste, que é o que a maioria das pessoas considera ser a realização do teste de caixa branca propriamente dito.

Os testadores executam os casos de teste seguindo o breve conjunto de instruções descritas em cada caso de teste e comunicando o resultado de cada caso de teste. Estes resultados podem ser comparados com os resultados esperados descritos no caso de teste para determinar se cada teste de caixa branca foi aprovado ou reprovado.

 

Passo 6: Repetir o ciclo conforme necessário

 

Tal como outras formas de teste de software, o teste de caixa branca consiste em comparar o funcionamento efectivo do sistema com as expectativas que os testadores têm sobre o funcionamento do sistema.

Se os testadores descobrirem que o sistema não está a comportar-se da forma esperada, isso pode significar que os testes de caixa branca falharam e que os programadores têm de corrigir as linhas de código antes de efectuarem mais testes.

Repita o processo acima para efectuar mais testes de caixa branca até que o sistema tenha sido completamente testado e quaisquer erros tenham sido corrigidos.

 

Melhores práticas para testes de caixa branca

As melhores práticas nos testes de caixa branca dependem do tipo de teste que está a realizar e da fase do processo de teste em que se encontra.

Uma vez que a maior parte dos testes de caixa branca tem lugar durante os testes unitários e os testes de integração, a maioria das melhores práticas de teste de caixa branca aplica-se a estas fases.

 

1. Maximizar a cobertura dos testes

 

Por definição, é importante maximizar a cobertura de teste ao realizar testes de caixa branca para garantir que uma alta porcentagem do software seja testada durante esta fase.

Pode fazê-lo maximizando a cobertura de caminhos e de ramos e escrevendo casos de teste que explorem todos os caminhos e resultados possíveis durante a fase de preparação.

 

2. Verificar o comportamento e o desempenho

 

Quando se está a escrever casos de teste em testes de caixa branca, pretende-se criar casos de teste que verifiquem se o sistema funciona como esperado, bem como casos de teste que verifiquem o desempenho do sistema.

Por exemplo, para além de verificar se determinadas acções conduzem a determinados resultados, pode também verificar a rapidez com que o sistema pode executar determinadas tarefas ou como o desempenho é afectado por diferentes variáveis.

 

3. Escrever casos de teste independentemente uns dos outros

 

Se pretender verificar duas características distintas, por exemplo, se uma classe de código depender de uma determinada base de dados, crie uma interface abstracta que reflicta esta ligação à base de dados e implemente uma interface com um objecto de simulação para testar esta ligação.

Isto garante que os seus casos de teste estão a verificar as ligações que pretende que verifiquem e não outra coisa qualquer.

 

4. Cobrir todos os caminhos e circuitos

 

Maximizar a cobertura dos testes significa cobrir todos os caminhos possíveis, considerando os loops condicionais e outros tipos de loops no código.

Certifique-se de que concebe casos de teste que exploram completamente os caminhos possíveis e verifique se os loops se comportam como esperado, independentemente da entrada.

 

7 Erros e armadilhas quando

Implementação de testes de caixa branca

Quando se começa a efectuar testes de caixa branca, é importante estar ciente de algumas das armadilhas mais comuns em que os programadores caem frequentemente quando efectuam testes de caixa branca. Os erros comuns nos testes de caixa branca podem causar atrasos e imprecisões que podem prejudicar a qualidade e o calendário do lançamento do software.

 

1. Pensar que os testes de caixa branca não são necessários

 

Alguns testadores pensam que os testes de caixa branca não são necessários, porque os testes de caixa preta testam todas as saídas externas do software e, se estas estiverem a funcionar correctamente, parte-se do princípio de que o funcionamento interno do sistema também está a funcionar.

No entanto, os testes de caixa branca podem ajudar os programadores a localizar problemas e erros que podem nem sempre aparecer nos testes de caixa preta e são essenciais para verificar a segurança dos sistemas de software.

Por exemplo, se um programa tem uma fuga de memória que provoca uma degradação do desempenho durante longos períodos de tempo que os testes de caixa negra não conseguem examinar, os testes de caixa branca são a única opção para analisar o código e encontrar o problema antes de um lançamento público alargado.

 

2. Efectuar todos os testes de caixa branca manualmente

 

Alguns programadores podem pensar que é tão fácil efectuar testes de caixa branca como de caixa preta.

No entanto, os testes de caixa branca são consideravelmente mais morosos e os programadores que tentam efectuar os testes de caixa branca de forma totalmente manual podem descobrir que é impossível efectuar verificações manuais de acordo com as normas desejadas ou maximizar a cobertura dos testes.

 

3. Atribuição de testadores para executar casos de teste

 

Os testes de caixa branca devem ser completamente efectuados por programadores, engenheiros de software e pessoas que compreendam completamente o funcionamento interno do sistema de software.

Alguns programadores pensam que podem passar os testes de caixa branca para os testadores de garantia de qualidade depois de terem escrito eles próprios os casos de teste, mas isso só resultará numa má execução e reduzirá a qualidade da documentação.

 

4. Apressar os ensaios

 

O teste de software é um processo longo e demorado, e alguns programadores podem sentir-se tentados a apressar o teste de caixa branca para passar à fase seguinte do desenvolvimento. É importante atribuir tempo e recursos suficientes aos testes de caixa branca para garantir que os programadores não se sintam apressados e que tenham tempo suficiente para maximizar a cobertura dos testes.

 

5. Documentação deficiente

 

Manter uma documentação adequada antes, durante e depois dos testes garante que todos os envolvidos no desenvolvimento e teste de software têm acesso às informações correctas no momento certo.

Certifique-se de que todos os membros da equipa de desenvolvimento sabem como redigir uma documentação clara e como comunicar os resultados dos testes de caixa branca.

 

6. Utilização incorrecta de ferramentas de automatização

 

As ferramentas de automatização podem facilitar a realização de testes de caixa branca, mas é importante certificar-se de que toda a sua equipa compreende quais as ferramentas de automatização que está a utilizar e como as utilizar.

Diferentes ferramentas são adequadas para diferentes tipos de testes, pelo que é importante escolher ferramentas de automatização que sejam adequadas para testes de caixa branca e aprender a utilizar correctamente as suas funcionalidades.

Por exemplo, algumas ferramentas não integram a automatização e, em vez disso, concentram-se na recolha de informações e na organização de bilhetes, o que está longe de ser ideal para testes automatizados. Pelo contrário, as ferramentas de pilha completa, como o ZAPTEST, abrangem todo o processo de teste através de funcionalidades como a automatização de qualquer tarefa, o que as torna adequadas para um trabalho de teste de caixa branca mais eficaz.

 

7. Não trabalhar com a equipa de garantia de qualidade

 

O facto de os testes de caixa branca serem planeados e executados pelos programadores não significa que a equipa de garantia de qualidade não deva estar envolvida de forma alguma.

É importante transmitir os resultados dos testes de caixa branca à equipa de garantia de qualidade, para que esta compreenda o que foi testado até ao momento e como os resultados dos testes de caixa branca podem afectar a forma como a equipa de garantia de qualidade aborda os testes de caixa preta.

Ao não envolver a equipa de garantia de qualidade, introduz-se uma potencial desconexão entre os diferentes departamentos, o que conduz a uma comunicação deficiente e a um pior feedback durante os testes. O resultado final desta situação é um nível de qualidade significativamente inferior no produto final.

 

Tipos de resultados dos testes de caixa branca

Quando efectua testes de software de caixa branca, recebe vários resultados em função dos resultados dos testes que realiza. Compreender estes resultados dos testes de caixa branca pode ajudá-lo a perceber quais os passos a dar a seguir.

 

1. Resultados dos testes

 

Os resultados dos testes de caixa branca dir-lhe-ão se é necessário continuar com mais testes, se existem defeitos que precisam de ser corrigidos e se cada caso de teste individual foi aprovado ou reprovado. É necessária uma documentação exaustiva porque ajuda os programadores e os testadores a compreenderem os resultados dos testes de caixa branca.

 

2. Defeitos

 

Os defeitos podem ser identificados nos testes de caixa branca e, por vezes, os resultados dos seus testes de caixa branca serão defeitos e bugs.

Se o sistema de software não se comportar como esperado durante os testes de caixa branca, isso pode indicar que existem defeitos graves no programa que devem ser reparados antes de continuar o desenvolvimento e os testes.

 

3. Relatórios de teste

 

Os relatórios de teste são relatórios compilados pelos programadores e testadores durante e após os testes de software.

Contêm detalhes dos resultados do teste, incluindo os casos de teste aprovados e reprovados, quaisquer defeitos encontrados durante o teste e recomendações para os próximos passos.

Os programadores utilizam os relatórios de teste para comunicar com outros programadores, cuja tarefa pode ser a correcção de falhas e erros encontrados durante os testes.

 

Exemplos de testes de caixa branca

Os testes de caixa branca permitem que os programadores verifiquem se a estrutura interna do sistema de software está a funcionar como deveria, independentemente dos resultados externos e das saídas do sistema.

Os exemplos abaixo ilustram como os testes de caixa branca podem ajudar os programadores a verificar as funções internas do software.

 

1. Exemplo de página de registo de comércio electrónico

 

Um exemplo de teste de caixa branca considera a forma como os programadores testam as funções de um sítio Web. Se estiver a tentar testar a página de registo de um sítio Web de comércio electrónico, os testes de caixa branca podem permitir aos programadores compreender se as funções e classes envolvidas no registo funcionam como deveriam quando a função de registo é executada.

Isto inclui especificamente todas as informações que um utilizador introduz e avalia os parâmetros por detrás do formulário, incluindo as datas que são e não são válidas e o que o formulário considera como um endereço de correio electrónico legítimo.

Em seguida, a equipa introduz uma série de cadeias de caracteres que testam o formulário, algumas concebidas para falhar e outras concebidas para ter êxito, antes de avaliar os resultados em relação aos resultados previstos.

Os testes de caixa negra, por outro lado, apenas verificam se a página em si funciona, sem qualquer análise adicional do porquê ou como.

 

2. Exemplo de calculadora

 

As calculadoras de aplicações constituem outro exemplo de teste de caixa branca.

Se estiver a criar uma calculadora que é utilizada como parte de uma aplicação, os testadores de caixa negra irão simplesmente testar se o resultado da calculadora está correcto quando esta é utilizada como pretendido.

Os testadores de caixa branca verificam os cálculos internos da calculadora para verificar como o resultado foi calculado e se está correcto. Isto é mais útil para cálculos mais complexos com várias fases, como os impostos. Os testadores examinam o código para ver os passos que a calculadora dá e a ordem em que os passos estão, antes de verem o resultado após cada etapa.

Se a entrada da calculadora for (7*4) – 6 e a saída for 22, isto está correcto e o teste da caixa negra passaria este teste. No entanto, isto deve-se ao facto de 7*4 = 28, e 28 – 6 é 22. Os testes de caixa branca podem revelar que o software encontrou este resultado executando 7*4 = 32, e 32 – 6 = 22, nenhum dos quais está correcto.

Esta maior percepção mostra que o cálculo é exacto após cada fase específica, encontra a fase em que pode não ser exacto e resolve-o mais rapidamente, uma vez que o testador pode ver claramente onde ocorre o problema.

 

Tipos de erros e bugs nos testes de caixa branca

Durante os testes de caixa branca, é possível identificar e localizar erros que podem afectar a forma como os sistemas funcionam sob o capô. Estes erros podem afectar funções externas ou podem afectar o desempenho ou a fiabilidade.

Alguns dos tipos mais comuns de erros e bugs que surgem durante os testes de caixa branca estão listados abaixo.

 

1. Erros lógicos

 

Os erros lógicos surgem nos testes de caixa branca porque os testes de caixa branca mostram áreas onde o programa não funciona logicamente ou onde as funções e condições são mal utilizadas no código do software.

Os erros lógicos podem apresentar-se como falhas do sistema ou simplesmente resultar em comportamentos e resultados inesperados.

 

2. Erros de concepção

 

Os testes de caixa branca podem ajudar os programadores a identificar erros de concepção no código. Os erros de concepção surgem quando existe uma diferença entre o fluxo lógico do software e a implementação efectiva do software. Podem resultar em comportamentos inesperados e erros de desempenho.

 

3. Erros tipográficos

 

Os erros tipográficos e as falhas de sintaxe são erros que surgem devido a erro humano – por exemplo, porque um programador escreveu mal uma determinada frase ou acrescentou a pontuação errada a uma linha de código. Pequenos erros como este podem resultar em funções quebradas e declarações que o software não consegue ler, o que pode causar grandes erros no sistema.

 

Métricas comuns de testes de caixa branca

Quando está a efectuar testes de caixa branca, as métricas de teste comuns podem ajudá-lo a medir o êxito e a abrangência dos seus testes de caixa branca, bem como a compreender a qualidade do trabalho dos seus programadores.

As métricas de teste informam o processo de desenvolvimento, uma vez que podem identificar áreas de melhoria ou orientar o processo de teste para o futuro.

 

1. Cobertura do código

 

Uma das principais características dos testes de caixa branca é que devem cobrir o máximo possível do código, e é possível medir a quantidade de código coberto com métricas de cobertura de código.

As métricas de cobertura de código mostram a quantidade de código total da aplicação que foi verificada através de testes de caixa branca. Geralmente, os programadores têm como objectivo cobrir o mais próximo possível de 100% do código do software através de testes de caixa branca.

A cobertura de código pode ser separada em métricas distintas, incluindo cobertura de caminho, segmento, instrução e ramo.

A cobertura de condição composta é outro tipo de métrica de cobertura de código que verifica se cada condição dentro de um conjunto foi verificada ao longo de vários caminhos e combinações de caminhos.

 

2. Métricas de defeitos

 

As métricas de defeitos reflectem o número de defeitos encontrados, a eficácia dos testes de caixa branca na identificação de defeitos e as percentagens de código que passam ou não nos testes de caixa branca.

A métrica dos defeitos pode ser apresentada como o número de defeitos por mil linhas de código ou o número total de defeitos no programa. Embora um baixo número de defeitos possa parecer positivo, os programadores devem certificar-se de que tal não se deve ao facto de os defeitos não serem detectados nos testes.

 

3. Execução do teste

 

As métricas de execução de testes podem ajudar os programadores a ver rapidamente que proporção do total de testes foi executada até à data e quantos testes ainda não foram executados. As métricas de execução de texto ajudam as equipas de software a compreender o progresso dos testes de caixa branca e se os testes de software automatizados estão ou não a funcionar como esperado.

No entanto, é possível haver falsos positivos e falsos negativos, o que pode afectar a precisão desta métrica.

 

4. Duração do ensaio

 

As métricas de duração do teste dizem-nos quanto tempo demora a executar testes automatizados, o que é particularmente importante nos testes de caixa branca, porque a automatização é essencial para maximizar a eficiência e a cobertura dos testes.

A duração dos testes é frequentemente um estrangulamento no desenvolvimento ágil de software, pelo que compreender quanto tempo demoram os testes de software a ser executados pode ajudar as equipas de desenvolvimento a acelerar o processo de desenvolvimento.

No entanto, é importante lembrar que as métricas de duração dos testes não dizem nada sobre a qualidade dos testes que está a executar.

 

Ferramentas de teste de caixa branca

As ferramentas e a tecnologia podem tornar os testes de caixa branca consideravelmente mais exactos, eficientes e abrangentes. As ferramentas de teste de caixa branca podem ajudar os engenheiros de software a automatizar os testes de caixa branca, a registar e documentar o processo de teste de caixa branca e a gerir os testes de caixa branca do início ao fim.

 

5 melhores ferramentas de teste de caixa branca gratuitas

Se não quiser investir já em ferramentas de teste de caixa branca dispendiosas, pode experimentar online uma série de ferramentas de teste de caixa branca gratuitas sem pagar nada.

As ferramentas de teste gratuitas nem sempre oferecem todas as mesmas funcionalidades que as ferramentas empresariais, mas são um bom ponto de partida para os principiantes nos testes de caixa branca e podem ajudar as equipas de desenvolvimento a compreender melhor as ferramentas e tecnologias de que necessitam.

 

1. ZAPTEST edição GRÁTIS

 

O ZAPTEST é uma ferramenta de teste de software e um software de automatização de processos robóticos que permite aos programadores e aos testadores de controlo de qualidade automatizar os testes de caixa branca e de caixa preta.

A versão gratuita do ZAPTEST permite vários utilizadores virtuais, várias iterações e suporte para fóruns de utilizadores. A aplicação funciona com fontes de dados locais e externas e integra-se com o HP ALM, Rally e JIRA. Os utilizadores que gostem da oferta gratuita do ZAPTEST e queiram ver mais do que a empresa oferece podem também perguntar sobre a actualização para a edição empresarial quando esta estiver pronta.

 

2. Bugzilla

 

O Bugzilla é uma ferramenta de teste de software de código aberto muito popular que permite aos programadores localizar bugs e defeitos no software e gerir o ciclo de vida dos bugs.

O Bugzilla facilita a atribuição de bugs a programadores, a definição de prioridades e a verificação de bugs, bem como o seu encerramento depois de corrigidos. O Bugzilla é uma excelente ferramenta para as equipas que ainda estão a tentar normalizar a sua abordagem à comunicação de erros e a sua utilização é totalmente gratuita.

 

3. OpenGrok

 

O OpenGrok é um navegador de código-fonte aberto e um motor de busca para bases de código. É compatível com código escrito em Java C++, JavaScript e Python, para além de outras linguagens de programação.

Se quiser navegar rapidamente numa grande base de código durante os testes de caixa branca, o OpenGrok é totalmente gratuito e fácil de utilizar.

 

4. Mapa SQL

 

O SQLmap é outra ferramenta de código aberto que é considerada quase essencial nos testes de caixa branca. O SQLmap regula o fluxo de exploração e detecção de erros de injecção de SQL.

Uma “ferramenta de teste de penetração” auto-descrita, o SQLmap pode ajudar os testadores de caixa branca a identificar e localizar erros de segurança no código-fonte e a corrigi-los antes de avançar.

 

5. Ema

 

Emma é um conjunto de ferramentas de código aberto que pode medir a cobertura do seu código se estiver a trabalhar em Java. É uma forma muito rápida de determinar rapidamente a cobertura do código e de controlar a quantidade de código que cada membro da equipa de desenvolvimento cobriu individualmente.

O Emma suporta cobertura de classes, métodos, linhas e blocos básicos e é totalmente baseado em Java.

 

5 melhores ferramentas de teste de caixa branca para empresas

Se procura ferramentas que ofereçam maior funcionalidade ou melhor suporte, as ferramentas de teste de caixa branca empresarial podem ser mais adequadas para a sua equipa de desenvolvimento.

 

1. Edição ZAPTEST ENTERPRISE

 

A edição empresarial do ZAPTEST é a versão melhorada do ZAPTEST gratuito. Nesta versão, os utilizadores podem beneficiar de modelos de OCR ilimitados, iterações ilimitadas e scripts VBScript e JavaScript ilimitados.

A edição empresarial da ZAPTEST oferece um conjunto mais completo de ferramentas para as equipas de desenvolvimento que pretendem mudar para a automatização, e a versão empresarial também inclui apoio especializado para garantir que a sua equipa tira o máximo partido da automatização de testes de software e da tecnologia RPA da ZAPTEST.

 

2. Violinista

 

O Fiddler é um conjunto de ferramentas da Telerik concebido para testar aplicações Web de caixa branca. O Fiddler pode registar todo o tráfego HTTP entre o seu sistema e a Internet e avaliar os pontos de interrupção definidos, bem como ajustar os dados de saída e de entrada. Está disponível em diferentes formatos, em função do seu orçamento e das suas necessidades, pelo que existe uma edição do Fiddler para quase todas as equipas.

 

3. Fortificar HP

 

O HP Fortify, anteriormente conhecido como Fortify, é outra ferramenta de teste de segurança que oferece soluções de segurança abrangentes para testes de caixa branca. O conjunto de ferramentas Fortify inclui a ferramenta Fortify Source Code Analysis, que analisará automaticamente o seu código-fonte em busca de vulnerabilidades que possam deixar a sua aplicação aberta a ciberataques.

 

4. Unidade ABAP

 

A versão empresarial do ABAP Unit permite que os programadores de software efectuem testes unitários manuais e automatizados de forma rápida e simples. Os programadores escrevem testes unitários na aplicação ABAP e utilizam esses testes para verificar as funções do código e identificar erros nos testes unitários.

As equipas de software que pretendam experimentar esta ferramenta podem começar com a versão gratuita da ABAP Unit antes de passarem para a edição empresarial.

 

5. LDRA

 

O LDRA é um conjunto proprietário de ferramentas que pode ser utilizado para cobertura de instruções, cobertura de ramos e cobertura de decisões ao efectuar testes de caixa branca. É uma excelente ferramenta se pretender verificar se o seu código-fonte cumpre os requisitos padrão de conformidade, rastreio e higiene do código.

 

Quando é que se deve utilizar a empresa

vs ferramentas de teste de caixa branca freemium?

As ferramentas de teste de software, tanto empresariais como freemium, têm o seu lugar em qualquer equipa moderna de desenvolvimento de software. À medida que a sua equipa cresce e os testes automatizados se tornam mais importantes para a sua abordagem de testes de caixa branca, é provável que queira deixar de trabalhar principalmente com ferramentas de teste gratuitas e passar a trabalhar com ferramentas empresariais que oferecem mais funcionalidades e utilizações ilimitadas.

No entanto, há cenários específicos em que as ferramentas freemium podem ser mais adequadas do que as ferramentas empresariais.

Muitos programadores optam por começar com ferramentas freemium quando estão a experimentar novas funcionalidades e tecnologias, principalmente para avaliar se estas tecnologias são adequadas para a sua equipa antes de investirem em tecnologias empresariais.

Pode também experimentar versões gratuitas de ferramentas empresariais, como o ZAPTEST, para as experimentar antes de as comprar e ficar a saber mais sobre o que as ferramentas empresariais oferecem.

Finalmente, algumas ferramentas freemium como o Emma e o Bugzilla especializam-se em funcionalidades de nicho mas importantes que oferecem vantagens contínuas mesmo às equipas de software preparadas para pagar por tecnologias empresariais.

 

Teste de caixa branca: lista de verificação, dicas e truques

Quando estiver pronto para efectuar testes de caixa branca, certifique-se de que tem tudo o que precisa antes de começar. Segue-se uma lista de aspectos a ter em conta antes de iniciar os testes de caixa branca para maximizar a cobertura dos testes e melhorar a exactidão dos resultados dos testes de caixa branca.

 

1. Utilizar ferramentas de automatização

 

As ferramentas de automatização podem acelerar enormemente o processo de realização de testes de caixa branca, bem como reduzir a taxa de erro e aumentar a precisão geral.

Hoje em dia, quase todas as equipas de software utilizam algum nível de automatização para efectuar testes de caixa branca, pelo que experimentar várias ferramentas e tecnologias de automatização antes de iniciar os testes de caixa branca pode ajudá-lo a escolher as ferramentas que pretende utilizar antes do início dos testes.

 

2. Objectivo: 100% de cobertura dos testes

 

É provável que não atinja o seu objectivo de 100% de cobertura de testes, mas o melhor é tentar aproximar-se o mais possível deste valor quando realiza testes de caixa branca.

Utilize ferramentas de cobertura de testes para acompanhar e medir métricas individuais, como a cobertura de caminhos e a cobertura de ramos, e garantir que todos os caminhos e ramos mais importantes do seu software foram cobertos durante os testes de caixa branca.

 

3. Elaborar relatórios de ensaio claros

 

Tal como acontece com outras formas de teste de software, certifique-se de que a sua equipa sabe como compilar relatórios de teste precisos e claros após a realização de cada fase do teste.

Um relatório de teste deve ser redigido num formato fácil de compreender e incluir pormenores sobre a abordagem de teste, bem como um resumo dos resultados de cada caso de teste executado. O relatório final deve justificar as medidas adoptadas e fazer recomendações para as próximas etapas.

 

4. Avalie o seu sucesso com métricas de teste

 

As métricas de teste ajudam as equipas de software a acompanhar e registar o progresso dos testes de caixa branca e oferecem informações valiosas que podem informar futuros processos de desenvolvimento.

É importante que os programadores utilizem métricas para compreenderem a eficácia dos testes que estão a realizar e a limpeza do seu código inicial, de modo a poderem melhorar o seu trabalho no futuro.

 

Testes de caixa branca:

Conclusão

O teste de caixa branca em engenharia de software é um tipo essencial de teste de software que verifica a estrutura interna e a lógica do código-fonte de uma aplicação de software.

Em conjunto com os testes de caixa preta, os testes de caixa branca verificam não só se o software funciona como esperado, mas também se o código interno é lógico, limpo e completo.

Os testes de caixa branca são mais frequentemente realizados em testes unitários e testes de integração, e são sempre efectuados por programadores e engenheiros de software com um conhecimento completo do código interno do software.

Embora alguns testes de caixa branca possam ser efectuados manualmente, actualmente muitos dos testes de caixa branca são automatizados devido às melhorias de velocidade, eficiência e cobertura que a automatização dos testes de caixa branca oferece.

 

FAQs e recursos

Se quiser saber mais sobre os testes de caixa branca, existem muitos recursos online gratuitos que pode consultar. Pode utilizar vídeos, livros e outros recursos para aprender a efectuar testes de caixa branca e garantir que as suas normas de teste de caixa branca seguem as melhores práticas.

 

1. Os melhores cursos sobre automação de testes de caixa branca

 

Se quiser saber mais sobre a automatização dos testes de caixa branca, pode fazer um curso sobre testes de software e testes de caixa branca. Alguns destes cursos são acreditados e oferecem qualificações formais, enquanto outros são cursos em linha informais concebidos para ajudar os programadores e os testadores de software que pretendem melhorar os seus conhecimentos sobre um determinado assunto.

 

Alguns dos melhores cursos de teste de caixa branca disponíveis on-line atualmente incluem:

 

• Edx: Teste automatizado de software

 

• Udemy: O Bootcamp Completo de Teste de Software 2023

 

• Udemy: Aprenda Cucumber BDD com Java

 

• Pluralsight: Testes automatizados: De ponta a ponta

 

2. Quais são as cinco principais perguntas da entrevista sobre automação de testes de caixa branca?

 

Se está a preparar-se para uma entrevista em que poderá discutir testes de caixa branca, técnicas de caixa branca e ferramentas de automatização, é importante que saiba.

 

• Qual é a diferença entre os testes de caixa branca e os testes de caixa preta?

 

• Porque é que os testes de caixa branca são importantes?

 

• Quais são algumas das diferentes abordagens que podem ser adoptadas para os testes de caixa branca?

 

• Que processos estão envolvidos nos testes de caixa branca e como podemos melhorá-los?

 

• Quais são algumas das ferramentas e tecnologias que pode utilizar para tornar os testes de caixa branca mais rápidos ou mais precisos?

 

3. Os melhores tutoriais do YouTube sobre testes de caixa branca

 

Se quiser saber mais sobre os testes de caixa branca, ver tutoriais no YouTube pode ajudá-lo a compreender como funcionam os testes de caixa branca e a ver explicações visuais dos processos e abordagens envolvidos nos testes de caixa branca.

Alguns dos tutoriais mais informativos do YouTube actualmente em linha incluem:

• Udacity: Exemplo de teste de caixa branca
• Guru99: O que é teste de caixa branca?
• Teste de caixa branca vs caixa preta
• Técnicas de teste de caixa branca
• Mentor de testes de software: O que é teste de caixa branca?

 

4. Como manter os testes de caixa branca

 

A manutenção dos testes de software garante que os testes que executa são exaustivos e adequados ao objectivo. É importante manter todos os tipos de testes de software, tanto em testes de caixa preta como de caixa branca, porque o código em que está a realizar os testes está constantemente a mudar com cada reparação de erros e iteração. Isto significa que os seus guiões de teste têm de mudar juntamente com ele.

A manutenção dos testes de caixa branca implica manter a sua estrutura de automatização de testes actualizada e aplicar processos concebidos para garantir que os testes e os casos de teste são actualizados regularmente.

 

Para tal, basta

 

Integrar a manutenção na concepção dos testes:

Considerar o futuro dos testes de caixa branca quando se constrói e concebe os testes de caixa branca facilitará a manutenção dos testes no futuro.

 

Permitir uma comunicação clara entre as equipas:

Certifique-se de que todos os membros da sua equipa de desenvolvimento têm vários canais de comunicação para que, assim que forem feitas alterações ao código, estas possam ser rapidamente reflectidas nos testes.

 

Ser adaptável:

Por vezes, é possível fazer alterações ao código que não foram planeadas. Certifique-se de que a sua equipa sabe como se adaptar rapidamente a estas alterações e tem as competências necessárias para acompanhar estas alterações nos testes.

 

Reavaliar constantemente os protocolos de teste:

Os protocolos de teste que implementou no início dos testes podem não ser adequados quando o seu software tiver sofrido várias alterações e melhorias. Reavalie os seus protocolos de teste em fases regulares para verificar se continuam a ser adequados.

 

5. Os melhores livros sobre testes de caixa branca

Os testes de caixa branca são um tema profundo que pode levar anos a dominar. Se quiser tornar-se um perito em testes modernos de caixa branca em testes de software, pode ler livros sobre testes de caixa branca escritos por programadores, académicos e engenheiros.

 

Alguns dos melhores livros actuais sobre testes de caixa branca e automatização de testes incluem

 

• A Arte do Teste de Software, Terceira Edição por Glenford J. Myers, Corey Sandler, Tom Badgett, Todd M. Thomas

 

• Software Testing: A Craftsman’s Approach, Fourth Edition, de Paul C. Jorgensen

 

• How to Break Software: Um Guia Prático de Testes por James Whittaker

 

• A automatização de testes de software “Just Enough” de Dan Mosley e Bruce Posey

 

Poderá encontrar estes livros em algumas livrarias e bibliotecas, bem como em linha. Pode também encontrar outros materiais de leitura e recursos de aprendizagem nas listas de leitura de bons cursos e programas de teste de software.

Download post as PDF