Nesta estratégia de teste o testador tem acesso a algumas das operações internas do sistema, mas normalmente a uma base de dados através de consultas SQL, não visualizando seu código.
Como sabemos a técnica de Caixa Branca tem acesso direto ao código-fonte da aplicação, validando assim sua estrutura interna, mas na técnica de Caixa Preta não conhecemos sua estrutura interna, sabendo só as entradas e saídas sem conhecer o que é feito com a entrada.
Ainda sobre as duas abordagens, sabemos que no Caixa Branca quem cria e executa é o próprio desenvolvedor testando através de testes unitários e no Caixa Preta quem cria e executa é o testador.
Nos testes de Caixa Cinza juntamos estas duas estratégias: conhecimento interno do produto e saídas esperadas. Não vamos confundi-lo com os testes de Caixa Branca, que cobre com testes a estrutura interna.
"Testes baseados no conhecimento do algoritmo, estados internos, arquitetura ou outras descrições mais alto-nível do comportamento do programa" [Doug Holffman]
Analisar as atividades por trás dos componentes durante o processo de execução de teste.
Dois tipos de problemas podem ser encontrados durante os testes de caixa-cinza:
- O componente encontra uma falha de algum tipo, fazendo com que a operação seja abortada. A interface com o usuário (front-end) ira indicar que ocorreu algum problema
- Os testes executam com sucesso, mas o conteúdo dos resultados está incorreto. Um sistema processando dados incorretos causa erro no resultado. [Elfriede Dustin]
Para aplicar esta estratégia utilizamos como suporte, por exemplo, consultas no banco de dados para confirmar que a consulta que os dados da consulta ou filtro que executamos na tela está de acordo com os dados existente no banco.
Esta estratégia é aplicada aos testes de WebServices, mesmo sem você se dar conta, pois você necessita conhecer a estrutura interna (arquido wsdl) e saber os resultados que devem ser obtidos neste tipo de teste.
O conhecimento interno do funcionamento pode ser de:
* Modelo de Arquitetura da aplicação
* Diagrama UML (diagrama de classe e/ou diagrama de sequência)
* Diagrama ER
Muita atenção: o testador não precisa conhecer o código-fonte da aplicação, e na minha opinião nem deve pois não é o seu papel. Mas conhecer a estrutura da aplicação é interessante para aprimorar a abrangência dos testes.
Por enquanto é isso!
Abraços e qualquer duvida: comentários!
