Peneirando Bugs

O Sr. Rex Black me surpreendeu ao apresentar o conceito de test granularity. Quando comecei a ler, pensei “mais que diacho de granulidade é essa?”, mas depois de ler, percebi que o conceito faz muito sentido. 😀

Testes de caixa-branca são focados nos detalhes da implementação, o código, a estrutura de dados, classes e os elementos de baixo nível do sistema. Portanto, eles são peneiras de grãos finos.

Já os testes de caixa-preta são focados nos riscos de qualidade, requisitos e na modelagem de alto nível. Assim sendo, eles são peneiras de grãos grossos.

Ou seja, tudo é uma questão de saber como peneirar os bugs. 🙂

E é importante lembrar, que os testes utilizando técnicas de caixa-branca (unitários e de integração), não excluem os testes utilizando técnicas de caixa-preta (sistema e aceitação), e vice-versa. Afinal, a combinação deles é sempre altamente recomendável e desejável.

E viajando um pouco além do conceito do Rex Black… como você escolhe feijões (será que alguém ainda faz isso hoje? rs), com uma peneira? Provavelmente NÃO, você precisa escolher com os olhos, colocando de lado aqueles grãos que estão ruins. E como você faz teste de interface? (não se parece um pouco com a maneira com que você escolhe feijões?)

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

R. Black, Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional, Wiley, 2007.

Imagens:

http://bit.ly/7tQL7U

http://bit.ly/7rEwux

Fuzz Testing

Um dos testes de Caixa Preta (Black Box) é o Fuzz testing, cuja tradução seria algo como teste aleatório. É uma técnica que consiste basicamente na inserção de dados aleatórios na aplicação, com o objetivo de descobrir falhas no programa, relacionadas com a inserção/leitura de dados, e, assim, melhorar a confiabilidade do software.

O procedimento de implantação do Fuzz testing é composto por três passos:

1. Preparar uma massa de dados de entrada para o seu programa;
2. Inserir a massa de dados no programa;
3. Verificar se ocorreu algum problema.

Para a preparação da massa de dados, geralmente é utilizado algum script/programa capaz de gerar dados aleatórios, sendo esses dados compostos muitas vezes por “dados ruins”, ou seja, dados que muitas vezes não são esperados pela aplicação como, por exemplo, caracteres especiais (@,$,%,¢,►,º,etc). A inserção dessa massa de dados também é feita pelo script/programa, ou até pela própria aplicação, por exemplo, abrindo o arquivo da massa de dados.

O Fuzz testing também pode ser usado com o propósito de segurança, pois a sua execução pode encontrar negligências e erros humanos, que colocariam a segurança da aplicação em xeque. Podendo, simular problemas que causariam a quebra, como por exemplo: buffer overflow, cross-site scripting (XSS para não confudir com CSS – Cascaded Style Sheet), ataques de negação de serviço e injeção SQL.

Vantagens

As falhas que a técnica de Fuzz testing pode encontrar são freqüentemente de ordem severa, podendo representar brechas de segurança que um hacker poderia explorar com o intuito de invasão. Outra vantagem é a contribuição para a robustez da aplicação que dará maior confiabilidade a mesma, evitando assim futuros problemas em produção.

Desvantagens

A principal desvantagem é que o Fuzz testing, geralmente só encontra falhas muito simples. E sua eficácia varia bastante de acordo com a pessoa que está implementando o teste, pois além da criação do script/programa, é ela que vai criar a massa de dados, ou seja, a massa de dados será o grande diferencial de um bom Fuzz testing para um mal.

Conclusão

Fuzz testing é uma técnica que permite descobrir falhas que provavelmente não seriam possíveis de serem encontradas de forma manual. Por isso a necessidade da automatização do teste, por meio da criação de um script/programa. A sua execução aumenta a confiança e solidez da aplicação.

Essa técnica ainda ajudará o programador a tomar futuramente as medidas preventivas de acordo com as falhas encontradas. Algumas dessas medidas são descritas no artigo do Elliotte Harold (vide fonte), para quem tiver interesse em conhecê-las, o artigo é muito bom.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

Harold E. Fuzz testing – Attack your programs before someone else does. IBM – Developer Works, 2006.

Fuzz testing – Wikipedia

Teste Estrutural (White Box) X Teste Funcional (Black Box)

Os testes de software são divididos em dois tipos:

Teste Estrutural: garantem que os softwares e os programas sejam estruturalmente sólidos e que funcionem no contexto técnico onde serão instalados [1]. Também conhecido como testes de White Box (Caixa Branca).

Teste Funcional: garantem o atendimento aos requisitos, ou seja, que os requisitos estão corretamente codificados [1]. Também conhecido como testes de Black Box (Caixa Preta).

Cada tipo de teste traz consigo diversas técnicas, sendo ela o processo que assegura o funcionamento adequado de alguns aspectos do sistema ou da unidade. Abaixo cito algumas destas técnicas, de acordo com o tipo de teste:

• Técnicas de Teste Estrutural
  • Testes de carga;
  • Testes de conformidade;
  • Testes de desempenho (performance);
  • Testes de estresse;
  • Testes de execução;
  • Testes de operação;
  • Testes de recuperação (contingência);
  • Testes de segurança;
  • Testes de sobrevivência.
• Técnicas de Teste Funcional
  • Teste de controle;
  • Teste de interconexão;
  • Testes paralelos;
  • Testes de requisitos;
  • Testes de regressão;
  • Testes de suporte manual;
  • Testes de tratamento de erros.

As técnicas de Testes Estruturais buscam garantir que o produto seja estruturalmente sólido e que funcione corretamente, o foco dos testes é averiguar o comportamento do sistema em determinadas situações. Já as técnicas de Testes Funcionais objetivam garantir que os requisitos e as especificações do sistema tenham sido atendidos, o foco dos testes é justamente a comparação do que foi planejado com o que foi produzido.

Em próximos artigos estarei detalhando cada uma das técnicas de testes, citadas aqui. Até lá!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

[1] Bastos, A.; Rios, E.; Cristalli, R. & Moreira, T. Base de conhecimento em teste de software. São Paulo, Martins Fontes, 2007.