Técnicas de teste – parte II

Tabelas de decisão

•  Utilizada para registrar regras de negócio complexas, baseadas em um conjunto de condições e ações.
• Cada regra define uma única combinação da condição de entrada
• Cada regra deve ser contemplada com pelo menos 1 caso de testes
• Tamanho da tabela é dado por 2N, onde N é o número de condições.
• Permite reduzir o número de casos de teste

Exemplo: seguradora de automóveis

Transição de estados

Testa a lógica do programa e não seus dados. Para modelar esta lógica são usadas máquinas de estado, que descrevem o comportamento de um sistema em resposta a estímulos internos ou externos. Para que possam ser usadas nos testes essas máquinas devem modelar a especificação corretamente, ser consistentes e representar de forma precisa os requisitos do sistema que será testado

Ela é uma abstração composta por um número finito de eventos (entradas), estados (condição de um objeto em um determinado momento; estados observados pelos usuários), ações (saídas e resultados que se seguem a um evento) e transições (relacionamento entre dois estados indicando que, quando um evento ocorre, o estado passa do anterior para o subseqüente). O modelo é chamado de diagrama de estados. Devem constar no modelo:

• Cada estado que o software pode assumir.
• As condições de entrada que levam de um estado a outro (clicar em um botão, entrar com um determinado dado)
• As saídas produzidas quando um estado é atingido ou deixado (exibir uma mensagem, exibir uma tela)

Se não tiver testes que cubram todos os nós/arestas, estão faltando testes.

Modelar softwares grandes e complexos podem criar máquinas de estado muito grandes. O que fazer para reduzir o número de estados e transições?

• Visitar cada estado pelo menos 1 vez. Não é necessário passar por todas as transições.
• Testar as transições que são usadas com mais frequencia (sim, é subjetivo)
• Testar todas os estados de erro e retorno destes estados.
• Utilizar o método “Dividir e conquistar” e modelar apenas parte do sistema (as partes mais críticas, que precisam ser testadas com mais cuidado

Estado inicial	Entrada	Estado final
1	B	1
1	A	2
2	A	2
2	B	1

 

Exercício:

A login deve ter entre 6 e 10 caracteres e devem constar apenas letras. O login é case sentive. A senha deve ter entre 6 e 10 caracteres e devem constar letras e números. A senha é case sentive. Cada login está associado a um único departamento.

Após digitar o login, a senha e o departamento corretos e clicar em “entrar”,  a tela inicial do software é exibida. Senão, uma mensagem de erro é exibida e o sistema continua na tela de login. Qual a máquina de estados resultante?

1.2 Caixa branca (white box)

• Nos testes caixa-branca, o o código da aplicação deve ser analisado, revisado em busca de falhas.
• Todos os caminhos independentes de um módulo devem ser exercitados pelo menos uma vez
• As decisões lógicas devem ser exercitadas para o resultado verdadeiro e falso
• Os ciclos devem ser executados dentro dos intervalos e no limites
• Todas as estruturas internas devem ser executadas
• Algumas técnicas de teste caixa branca são: revisão formal (peer review, inspeção e, walktrough), teste de caminho básico.

1.2.1  Revisão formal

É uma revisão do código fonte sem executá-lo. Os elementos da revisão formal são:

• Identificar problemas. Sejam eles falhas ou coisas que estão faltando
• Seguir as regras. Antes de iniciar a revisão, devem ser definidas regras como, por exemplo, quantos linhas de código serão revisadas, quanto tempo durará a revisão, etc. Estas regras devem ser seguidas para que cada participante saiba qual é o seu papel e o que esperar da revisão
• Preparação. Cada participante deve se preparar para a revisão. Ele deve saber com antecedência quais serão suas tarefas e responsabilidades. Muitos dos problemas são encontrados durante a preparação.
• Reporte. Elaborar um relatório com os resultados da revisão descrevendo quais foram os problemas encontrados, onde eles foram encontrados, etc.

Como consequênncias da revisão formal temos:

• Melhora da comunicação interna. Programadores inexperientes aprendem com os mais experiêntes, os testadores passam a ter uma idéia do que eles estão testando…
• Aumento da qualidade. Como o código será analisado por outras pessoas, os programadores passam a ter mais cuidado com o que estão produzindo (“para não passar vergonha”)

As revisões formais são:

• Peer review: revisão feita por pares (1 ou 2 pessoas, no máximo) do programador (programadores e tesstadores).
• Walkthrough: o programador faz uma apresentação formal para um grupo pequeno de revisores (programadores e tesstadores). Os revisores devem receber uma cópia do programa antes da revisão e estudá-la.
• Inspeção: é a mais formal das revisões. O apresentador não é o desenvolvedor do código. Isto o obriga a estudar e entender o código. Os inspetores devem avaliar o código sob as diferentes visões, tais como usuário e do suporte. Um dos inspetores deve avaliar o código de trás pra frente. Deve existir um moderador e um redator. Depois de encontrados os problemas, o redator faz um relatório, o programador corrige as falhas e o moderador verifica se elas foram corrigidas.

1.2.2.             Teste do caminho básico

 Garante que cada comando do programa será executado pelo menos uma vez durante o teste. O programa deve ser representado utilizando grafos de fluxo de controle.

Fonte: Roger Pressman

Um caminho independe é um caminho que possui pelo menos um novo comando no grafo de fluxo de controle (uma aresta que ainda não foi utilizada). Exemplo (Fonte: Roger Pressman):

Caminhos:

• Caminho 1: 1-11
• Caminho 2: 1-2-3-4-5-10-1-11
• Caminho 3: 1-2-3-6-8-9-10-1-11
• Caminho 4: 1-2-3-6-7-9-10-1-11

 O caminho 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 não é um caminho independente, porque é apenas uma combinação de caminhos já especificados e não atravessa nenhuma nova aresta.

Para saber quantos caminhos um software tem,usa-se a Complexidade ciclomática (teoria dos grafos). Ela é uma métrica que fornece uma medida quantitativa da complexidade lógica de um programa. Ou seja, quantos caminnhos, no máximo, terão que se exercitados para garantir a cobertura de todos os comandos do programa.

Fórmulas:

1)    V(G) = E – N+2, onde E é o número de arestas e N é o número de nós

2)    V(G) = P + 1, onde P é o número de nós predicados.

Para o exemplo anterior:

1)    E = 11; N = 9, V(G) = 11 – 9 + 2 = 4

2)    P = 3, V(G) = 3+1 = 4

Exemplo:

1. { int n, lastc, c; n = 1; lastc = getchar();

2.  while(lastc != ENDFILE)

3.          {if ((c = getchar()) = = ENDFILE) {

4.                  if ((n > 1 | | (latsc = = warning))

5.                      putrep (n, lastc);

6.                  Else putchar (lastc);

7.                  }

8.              Else {if (c = = lastc)

9.                           n+ +;

10.                    elseif ((n > 1) | | (lastc = = warning)) {

11.                               putrep (n, lastc) ; n = 1; }

12.                    Else putchar (lastc);

13.             }

14.             lastc = c;

15.          }

16.      }