Le temps de l’avion et le temps du désert

Com a linguagem SATEL pode-se definir intenções de teste que se relacionam directa- mente com as possibilidades de execução (i.e., os diversos comportamentos) ao longo do funcionamento do SUT. Em rigor, cada intenção de teste corresponde a um sub- conjunto do conjunto de execuções hipoteticamente exequíveis no âmbito do compor- tamento do sistema (e.g. intenção de teste só sobre o login no Sistema) e podem (as intenções) ser especificadas através da indicação da restrição de variáveis que repre- sentam diferentes dimensões das fracções do sistema que devem ser testadas.

Do parágrafo anterior pode-se concluir que a SATEL é uma linguagem que serve como driver da geração de teste. Pode-se indicar a forma dos caminhos de execução como se de uma expressão regular se se tratasse, acrescentar algumas condições sobre esses caminhos ou sobre variáveis de estímulo e de observação e assim obter testes de uma forma controlada, abrangendo determinada funcionalidade especificamente.

Como se pode observar na gramática e no metamodelo em apêndice, as intenções de teste são expressas através de um conjunto de fórmulas baseadas nas fórmulas HML (Hennessy-Milner [17, 24]), às quais foram adicionadas variáveis, e que em [17] pas- sam a designar-se por padrões de execução já que subentendem a descrição da execu- ção de alguma parte do sistema. São fórmulas que permitem ao engenheiro de teste guiar a geração dos testes mediante diferentes critérios, condições e hipóteses, já que a sua sintaxe permite, entre diversos aspectos, definir a configuração dos caminhos de execução, a configuração/padrões das operações do SUT e dos respectivos parâmetros dos métodos e gates (outputs e gates) (a estas possibilidades chamamos hipótese de regularidade). Outras hipóteses oferecidas pela SATEL são a de uniformidade e de su- buniformidade aplicáveis sobre variáveis e que se referem à possibilidade de redução dos casos de teste através da selecção, quer de um único valor do domínio das variá- veis algébricas (uniformidade) , quer de vários (subuniformidade). Estas duas últimas hipóteses estão contempladas como trabalho futuro desta dissertação.

De uma forma mais informal e com o fim de tornar a compreensão da SATEL mais fácil para o leitor introduzir-se-á a linguagem passo-a-passo começando-se com as

3. TRABALHO RELACIONADO 3.2. SATEL

questões mais básicas.

Desta forma, com a SATEL a especificação de um modelo centra-se num ponto ful- cral, que são os axiomas das intenções de teste aqui apresentadas com sintaxe similar à proposta, tanto pelo autor como pelos trabalhos desta dissertação.

Tome-se como exemplo, o Counter, introduzido na secção anterior, e faça-se uma extensão de forma a torná-lo minimamente compatível com a notação CO-OPN. Na figura 3.2 pode-se ver que o modelo é o mesmo, mas foram-lhe adicionados os mé- todos (tick e mark), e gates (mark e time(Counter)). Semanticamente, após esta adição, as transições acima só serão disparadas quando se reunirem as condições explicitadas no capítulo anterior sobre a semântica das APN, i.e., se as guardas forem satisfeitas e existir uma subsituição de variáveis, e doravante, se for também recebido um estímulo externo, neste caso, através do método tick. Por seu turno, a transição abaixo, uma vez disparada, despoletará o funcionamento da gate time, fornecendo dados do interior da APN para fora, neste caso permitindo uma observação do valor da variável algébrica counter. tick alarm mark time(counter) increment finished lt(counter ,suc^10(zero))=true counter zero suc(counter) eq(counter,suc^10(zero))=true counter counter zero

Figura 3.2: Rede de Petri Algébrica Encapsulada de um Contador

Posto isto, tem-se já o necessário para prosseguir com uma introdução informal sobre a linguagem SATEL. Parta-se do princípio que se quer testar o seguinte funcio- namento:

• a APN responde a vários estímulos tick

• ao fim de n estímulos o valor de counter observado aquando da transição é sucn_{(zero)ou zero, caso n = 0 e nesse momento se por acaso for dado o estímulo}

markdeve ser feita uma observação time(counter), em que counter = sucn_(zero)

Para este caso devem ser gerados testes em que o counter está de acordo com mo- 36

3. TRABALHO RELACIONADO 3.2. SATEL

delo e também testes em que isso não acontece, fornecendo assim um oráculo verda- deiro ou falso, respectivamente.

Para este exemplo, defina-se duas intenções de teste:

TickIntention intenção para gerar caminhos de execução onde se dá o estímulo tick

sucessivamente

MarkIntention intenção para gerar o último traço de execução após a geração com a

intenção T ickIntention

Para cada uma das intenções podemos ter diversos axiomas com os quais se ex- prime a configuração dos caminhos de execução nessa intenção. De uma forma geral um axioma tem a seguinte forma:

❬❈♦♥❞✐t✐♦♥❪✬❂❃✬■♥❝❧✉s✐♦♥

A estrutura sugere que se possa lê-la (informalmente) como se de uma implicação se tratasse. À esquerda têm-se condições sobre o axioma que limitam a aplicação do mesmo e que constrangem variáveis. As condições são, como sugere a sintaxe, opci- onais. À direita tem-se a Inclusão que é o membro onde se define a configuração do padrão que estamos a gerar, bem como a intenção de teste a que pertence esse padrão.

Observe-se os seguintes axiomas:

• Top in ❚✐❝❦■♥t❡♥t✐♦♥;

• path in ❚✐❝❦■♥t❡♥t✐♦♥, nbEvents(path) < 6 =><tick> . path in ❚✐❝❦■♥t❡♥t✐♦♥;

• lt(Counter, suc6_{(zero)) = true, path in ❚✐❝❦■♥t❡♥t✐♦♥ => path . <mark with time(Counter)> in}

▼❛r❦■♥t❡♥t✐♦♥;

O primeiro axioma é um axioma da intenção ❚✐❝❦■♥t❡♥t✐♦♥ e neste não são espe- cificadas quaisquer condições. Para este axioma apenas se está a gerar o padrão de execução Top, ou seja vazio; é o equivalente ao símbolo λ na definição de gramáticas. Portanto, este axioma é, como iremos ver, um auxiliar.

O segundo axioma possui duas condições: exige que a variável de caminho - path - esteja instanciada com padrões de execução gerados por um axioma pertencente à intenção❚✐❝❦■♥t❡♥t✐♦♥ e requer que o número de eventos desse padrão seja inferior a 6. Satisfeitas as condições, este axioma gerará padrões em que concatena o padrão path com uma sincronização, cujo estímulo é o evento < tick >. Note-se que o operador ponto (.) é o operador de concatenação de caminhos de execução.

Estes dois axiomas pertencem ambos à intenção❚✐❝❦■♥t❡♥t✐♦♥. Numa analogia, em termos de funções recursivas, o primeiro é um caso de base e o segundo é um axioma recursivo, já que requer que a variável path esteja instanciada com padrões da intenção ❚✐❝❦■♥t❡♥t✐♦♥ e a partir disso gera mais padrões para essa intenção de teste.

3. TRABALHO RELACIONADO 3.2. SATEL

Em termos práticos estes dois padrões juntos gerariam os seguintes traços:

• ❁t✐❝❦❃✳❚♦♣ • ❁t✐❝❦❃✳❁t✐❝❦❃✳❚♦♣ • ❁t✐❝❦❃✳❁t✐❝❦❃✳❚♦♣ • ❁t✐❝❦❃✳❁t✐❝❦❃✳❚♦♣ • ❁t✐❝❦❃✳❁t✐❝❦❃✳❁t✐❝❦❃✳❚♦♣ • ❁t✐❝❦❃✳❁t✐❝❦❃✳❁t✐❝❦❃✳❁t✐❝❦❃✳❚♦♣ • ❁t✐❝❦❃✳❁t✐❝❦❃✳❁t✐❝❦❃✳❁t✐❝❦❃✳❁t✐❝❦❃✳❚♦♣

(Note-se que apenas seis eventos são admitidos pelo segundo axioma, dada a se- gunda condição, em relação à variável path.)

O terceiro axioma não é recursivo. Este exige que a variável path contenha padrões na intenção❚✐❝❦■♥t❡♥t✐♦♥ (lado esquerdo do axioma), para a partir disso gerar padrões de execução para a intenção de teste▼❛r❦■♥t❡♥t✐♦♥ (lado direito do axioma).

Aproveitando este axioma para introduzir a noção de❈♦♥❞✐t✐♦♥❆t♦♠, neste axioma, tem-se portanto dois ❈♦♥❞✐t✐♦♥❆t♦♠, sendo o segundo um ■♥❝❧✉s✐♦♥ (uma restrição sobre o domínio da variável de caminho). Às variáveis de caminho atribuímos o tipo ❍▼▲Pr✐♠✐t✐✈❡.

Os ■♥❝❧✉s✐♦♥ são, como se pode ver, ambivalentes: servem como ❈♦♥❞✐t✐♦♥❆t♦♠ e constituem também o lado direito do axioma.

O primeiro❈♦♥❞✐t✐♦♥❆t♦♠ é uma igualdade algébrica (❆❧❣❊q✉❛❧t✐t②) e é uma restri- ção sobre uma variável algébrica (neste caso do sort♥❛t). Serve para obrigar a que a igualdade lt(Counter, suc6_{(zero)) = trueseja verdadeira (i.e., que se possa reescrever}

o termo do lado esquerdo da equação no do lado direito).

Com a aplicação deste axioma seriam concatenados aos padrões já gerados pe- los dois primeiros axiomas o padrão <mark with time(Counter)>, em que a variável Counter seria resolvida para os valores do conjunto {zero, sucn_{(zero)}com n ∈ {0..5}.}

Assim sendo, obter-se-iam as seguintes soluções finais:

• ❁t✐❝❦❃✳❚♦♣✳❁♠❛r❦ ✇✐t❤ t✐♠❡✭❈♦✉♥t❡r✮ • ❁t✐❝❦❃✳❁t✐❝❦❃✳❚♦♣✳❁♠❛r❦ ✇✐t❤ t✐♠❡✭❈♦✉♥t❡r✮ • ❁t✐❝❦❃✳❁t✐❝❦❃✳❚♦♣✳❁♠❛r❦ ✇✐t❤ t✐♠❡✭❈♦✉♥t❡r✮ • ❁t✐❝❦❃✳❁t✐❝❦❃✳❚♦♣✳❁♠❛r❦ ✇✐t❤ t✐♠❡✭❈♦✉♥t❡r✮ • ❁t✐❝❦❃✳❁t✐❝❦❃✳❁t✐❝❦❃✳❚♦♣✳❁♠❛r❦ ✇✐t❤ t✐♠❡✭❈♦✉♥t❡r✮ • ❁t✐❝❦❃✳❁t✐❝❦❃✳❁t✐❝❦❃✳❁t✐❝❦❃✳❚♦♣✳❁♠❛r❦ ✇✐t❤ t✐♠❡✭❈♦✉♥t❡r✮ 38

3. TRABALHO RELACIONADO 3.2. SATEL

• ❁t✐❝❦❃✳❁t✐❝❦❃✳❁t✐❝❦❃✳❁t✐❝❦❃✳❁t✐❝❦❃✳❚♦♣✳❁♠❛r❦ ✇✐t❤ t✐♠❡✭❈♦✉♥t❡r✮

Por definição, uma solução final é uma solução derivada a partir de um axioma que gera testes para uma intenção de teste que não é referenciada por nenhum ConditionA- tom(■♥❝❧✉s✐♦♥) dos restantes axiomas, ou que o sendo, seja pelo próprio axioma. Nesse caso o axioma é recursivo. Se se considerar um grafo onde cada vértice representa um axioma e os respectivos arcos orientados representam a dependência entre os axiomas, então as soluções finais serão as que forem geradas a partir de um axioma, cujo vértice não aceita arcos de entrada, i.e. é um vértice fonte. Visualmente, para o exemplo em análise, a figura 3.3 mostra que o terceiro axioma produz os testes finais.

Axioma 1 Axioma 2 Axioma 3

Figura 3.3: Grafo de dependências entre axiomas

Finalmente, após a geração dos testes o último passo seria obter os oráculos para cada um dos testes. Assim ter-se-iam alguns testes que deverão passar e outros não. Mostra-se em seguida um subconjunto reduzido de alguns testes e respectivo oráculo. Verdadeiro: ❁t✐❝❦❃✳❁♠❛r❦ ✇✐t❤ t✐♠❡✭s✉❝✭③❡r♦✮✮❃

Verdadeiro: ❁t✐❝❦❃✳❁t✐❝❦❃✳❁♠❛r❦ ✇✐t❤ t✐♠❡✭s✉❝✭s✉❝✭③❡r♦✮✮✮❃ Falso : ❁t✐❝❦❃✳❁t✐❝❦❃✳❁♠❛r❦ ✇✐t❤ t✐♠❡✭s✉❝✭s✉❝✭s✉❝✭s✉❝✭③❡r♦✮✮✮✮✮✮❃

Note-se que nos testes cujo oráculo é✈❡r❞❛❞❡✐r♦, o número de eventos t✐❝❦ corresponde ao valor da variável❈♦✉♥t❡r devolvida pela gate t✐♠❡.