Os testes de caixa preta são casos de testes construídos tendo como base as especificações e funcionalidades do software. Estes testes usam as descrições externas do software, incluindo especificações, requisitos e design para elaborar casos de teste. O tester selecciona entradas válidos e inválidos e determina a saída correcta. Neste tipo de testes não existe qualquer conhecimento da estrutura interna do objecto de teste.
Se é necessário executar um número infinito de testes então é necessário transformar esta infinidade numa quantidade adequada de trabalho. As técnicas de teste de software existem para reduzir o número de testes a ser executados, enquanto fornecem uma cobertura suficiente do sistema em análise.
State Transition Testing
A maioria dos sistemas nos quais é necessário efectuar testes, possuem um número demasiado grande, ou mesmo infinito de possíveis situações de teste. Por exemplo, apesar do facto de que um telemóvel possuir um número finito de funções, a utilização destas funções podem ser combinadas num número infinito de possibilidades. Este testes são usados quando o sistema, ou uma parte do sistema pode ser descrito como um diagrama de estados. Estes testes podem ser construídos para cobrir uma sequência típica de estados, cobrir todos os estados, verificar todas as transições, uma sequência especifica de transições ou testar transições inválidas.
Sendo assim temos de pegar num sistema e transforma-lo num diagrama de estados.
Desenhar o diagrama de estados associado ao objecto em testes
Um diagrama de estados é composto por estados e transições. Cada estado é geralmente representado por um circulo, e a transição por uma seta.
Mais informação sobre a construção de diagramas de transição de estados ver: (http://en.wikipedia.org/wiki/State_transition_table)
Determinar os estados iniciais, as entradas permitidas e os resultados esperados assim como os resultados finais
Depois de desenhado o diagrama há que determinar os estados iniciais (tipicamente pontos de entrada do caso em teste) e os estados finais (tipicamente os pontos de saída).
Determinar o nível de cobertura que se pretende alcançar
Existe uma série de modos diferentes de medir a cobertura quando usando testes por transição de estados. Num desses modos, a cobertura pode ser medida pelo número de sequências de transições. Esta medição é conhecida como “(n-1) switch”. N-Switch coverage representa a percentagem de sequencias de N-transições que são avaliadas por uma suite de testes. Os níveis de cobertura mais usado é o “0-Switch coverage” que define que é testado uma transição.
Desenhar a árvore de testes
A partir de uma tabela de transição de estados podemos definir um conjunto de casos de testes mínimos. Para tal devemos começar por colocar os estados iniciais como raiz da árvore e colocar todas as transições válidas para cada um destes estados. Repetir o passo anterior e colocar as transições válidas para cada um destes novos estdos. Repetiro processo até que não existam mais transições válidas. Não devem ser repetidas transições.
Definir os testes
Para determinar qual o conjunto de testes a executar deve-se pegar em todos os caminhos possíveis na árvore. Cada um destes caminhos dá origem a um caso de teste.
Exemplo
Um exemplo prático onde esta técnica pode ser aplicada é um típico workflow da gestão de defeitos. Pegando então nesse workflow temos o seguinte: (Obs: Por motivos de simplificação dos diagramas estão omitidas na análise as transições para o próprio estado)
Tabela de Transições de estado
De seguida apresenta-se a tabela com as transições válidas no workflow definido pela imagem acima.
| | Open | Fixed | ReOpen | Answer Only | Rejected | Closed |
| Open | | X | | | X | |
| Fixed | | | X | | | X |
| ReOpen | | X | | | X | |
| AnswerOnly | | | | | | |
| Rejected | | | X | X | | |
| Closed | | | | | | |
A partir de uma tabela de transições de estados ou de um diagrama desenhamos então uma árvore, que nos ajudará a identificar os casos de teste necessários.
A partir desta árvore identificam-se claramente cinco casos de teste para testar o workflow de gestão de defeitos que correspondem às seguintes sequências:
- Open –> Fixed –> Closed;
- Open –> Fixed –> Reopen-> Fixed;
- Open –> Fixed –> Reopen->Rejected;
- Open –> Rejected –> Answer Only;
- Open –> Rejected –> Reopen;
Obviamente estas não correspondem a todas as possíveis combinações para a edição de um defeito. Mas é garantido que neste conjunto de casos de testes todas as transições são executadas e todos os estados estão cobertos. Muito mais poderia ser escrito sobre o tema mas penso que fica cá resumido o essencial.
Bom, até à próxima.