Testes de Software: Como Testar?

Essa pergunta é respondida através das técnicas de testes.

As técnicas de testes de software são divididas em 2

Testes Caixa Branca

Caixa-branca, algumas vezes chamados de testes estruturais, é projetado em função da estrutura interna do sistema (código), permitindo em teoria uma verificação mais precisa do funcionamento do software.

O teste caixa-branca é derivado de testes com base na estrutura interna ou na implementação do sistema. A estrutura interna pode incluir código, arquitetura, fluxos de trabalho e fluxos de dados dentro do sistema.

A técnica de teste de caixa-branca é recomendada para as fases de teste de unidade e teste de integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do sistema, que por sua vez conhecem bem o código produzido.

Testes de Caminhos

Permite derivar uma medida de complexidade lógica de um algoritmo e usar essa medida como guia para definir um conjunto base de caminhos de execução.

Esta técnica testa as decisões existentes no código e o código executado com base nos resultados da decisão.

A notação que representa o fluxo de controle é chamada de grafo de fluxo (ou grafo de programa).

Teste e cobertura de instruções

Testa as instruções executáveis do código.

A cobertura é medida pela seguinte formula:

Essa porcentagem irá mostrar a cobertura dos testes em relação a suas instruções.

Sobre a cobertura de Testes de Caixa Branca

Quando a cobertura de 100% das instruções é alcançada, garante-se que todas as instruções executáveis no código tenham sido testadas pelo menos uma vez, mas não garante que toda a lógica de decisão tenha sido testada.

O teste de decisão possui mais cobertura que um teste de instrução, quando uma cobertura de decisão de 100% é alcançada, representa-se que todos os resultados de decisão foram testados, o que inclui testar os resultados verdadeiro e falso, mesmo quando não há uma instrução falsa explícita. Atingir 100% de cobertura de decisão garante 100% de cobertura de instrução

Testes Caixa Preta

 As técnicas de teste caixa-preta, que também podem ser chamadas de técnicas comportamentais (baseadas no comportamento do usuário), são elaboradas a partir de uma análise de base de teste, como:

• Documento de Requisito de Softwares;

• Casos de Uso;

• Estórias de Usuário;

• Processo de negócio;

As técnicas de testes caixa pretas são aplicáveis a testes funcionais e não funcionais (itens que iremos ver nos próximos artigos). Basicamente um testes de caixa preta consiste em aplicar entradas para teste e fazer uma análise das saídas conforme as exigências ad base de testes, sem ter as referências internas do software (abrir e analisar código).

Testes Baseados em Cenários

Os cenários de testes são uma sequência de ações (condições de execução) que identifica comportamentos de interesse no contexto de execução de teste.

O teste de cenário de teste utiliza as características fornecidas pelo cenário como entradas do teste e compara com suas eventuais saídas esperadas conforme o comportamento do cenário, o cenário de teste comporta vários casos de usos, e tem interpretação próxima aos casos de teste.

Testes Baseados em Casos de Uso

Testes baseados em casos de uso, tem como premissas os comportamentos descritos nos casos de usos , avaliando se as funcionalidades descritas nos casos de usos possuem o comportamento desejado.

É mais simplificado em relação aos testes de cenários.

Particionamento de equivalência  - Conforme ISQTB - Foundation Level Syllabus –  O particionamento de equivalência divide os dados em partições ou classes de equivalência, de tal forma que todos os membros de uma determinada partição devem ser processados da mesma maneira

• Partição de Equivalência Válida: valores válidos são valores que devem ser aceitos pelo componente ou sistema.

• Partição de Equivalência não-válida: valores inválidos são valores que devem ser rejeitados pelo componente ou sistema.

As partições podem ser identificadas para qualquer elemento de dados com ligação direta ao objeto de teste:

• Entradas

• Saídas

• Valores internos

• Valores relacionados a tempo

• Parâmetros de interface

Partições, também podem ser dividias em superstições, obedecendo algumas regras:

• Cada valor deve pertencer a uma e apenas uma partição de equivalência.

• Quando partições de equivalência inválidas são usadas em casos de teste, elas devem ser testadas individualmente, ou seja, não podem ser combinadas com outras partições de equivalência inválidas, para garantir que as falhas não sejam mascaradas.

Análise de valor limite - Testes de Valores Limites

A análise de valor limite é uma extensão do particionamento de equivalência, mas só pode ser usada quando a partição é ordenada, consistindo em dados numéricos ou sequenciais. Os valores mínimo e máximo (ou primeiro e último valores) de uma partição são seus valores limites (Beizer, 1990).

Por exemplo, imagine que em uma tela de setup de máquina um dos campos aceite um valor inteiro para o setup, sendo que o campo foi configurado de tal forma que não será possível colocar um valor não inteiro e que o intervalo válido é de 1 a 100, nesse caso a partição de intervalo válido é de 1 a 100, a partição inválido muito alta pode ser de 101 a 110, por exemplo e para partição inválida de limite muito baixo seria 0.

É essa é uma análise simples, para testes dos limites da aplicação, veja que garanto que sem procedimentos de testes de software, muitos responsáveis de projeto e programadores irão testar somente os valores válidos e com sorte um limite superior ou inferior.

Teste de tabela de decisão

Técnicas de teste combinatórias são úteis para testar a implementação de requisitos do sistema, uma vez que irão especificar diferentes combinações de entrada que podem levar a diferentes combinações de saída.

Para elaboração de tabelas de decisão, até mesmo tabelas da verdade, podem ser ferramentas úteis para prever as saídas desejadas dependendo do nível do teste.

Para elaborar tabelas de decisão o testador identifica as entradas e as saídas do sistema.

Assim como definição, podemos dizer que é uma maneira de expressar, em forma de tabela, qual o conjunto de decisões (entradas) são necessários, para que algumas ações (estímulos) produzam o resultado esperado (saídas). Sendo que as ações são definidas pelas regras de decisão.

Na tabela acima temos um exemplo de um formato comum de uma tabela de decisão, sendo que, para o exemplo já foi feito uma análise preliminar para retirar os estados que não são aplicáveis.

Teste de transição de estado

 O teste de transição de estado é utilizado para testar a capacidade que o software tem de entrar e sair de estados definidos através de transições válidas ou inválidas.

As transições de estado podem ser rastreadas em um diagrama de transição de estados que mostra todas as transições válidas entre estados em um formato gráfico, já a tabela de estados mostra as possíveis transições válidas ou inválidas.

Modelo Moore para Transição de Estados

Nesse modelo as saídas dependem unicamente dos estados e as ações são executadas quando entra-se no estado.

Modelo de Mealy

 Nesse modelo as saídas dependem das entradas e dos estados e as ações são executadas conforme a entrada fornecida.

  Bom, a pergunta - como testar? - está respondia, nos vemos no próximo artigo sobre testes de software.

Bibliografia:

Foundation Level Syllabus - Versão 2018br - Brazilian Software Testing Qualifications Board - BSTQB