Padrões de Teste Documentados

Os padrões de teste utilizados nesse trabalho são: (i) Round-trip Scenario Test [11]; (ii)

Abstract Class Test[11]; (iii) Error Simulator [28]; e (iv) Test Case With Time Specification

[28]. Alguns desses padrões não são, originalmente, descritos para a geração de casos de teste interessados na interação entre as classes. No entanto, eles podem ser utilizados para este fim. Para isso, foram feitas algumas modificações, o que não descaracteriza o contexto do padrão, de forma a adaptá-los para teste de integração, o foco deste trabalho. A seguir, é apresentado o padrão Round-trip Scenario Test documentado de acordo com o formato de definição descrito anteriormente. Os demais padrões podem ser encontrados no Apêndice A.

3.3 Identificação da Aplicação de Padrões de Teste 38

Round-trip Scenario Test

Este padrão consiste na geração de casos de teste a partir de caminhos em um grafo de fluxo extraído a partir de diagramas de sequência UML. Ele foi escolhido porque sua solução permite a geração de casos de teste para caminhos completos do diagrama de sequência, permitindo a verificação das interações entre classes, e consequentemente, sendo apropriado para teste de integração. Seguindo o formato de definição descrito na seção anterior, tem-se:

• Nome: Round-trip Scenario Test.

• Contexto: Cenários round-trip são caminhos completos nos diagramas de sequência. Diagramas de sequência geralmente incluem estes cenários, porém nem sempre explícitos.

• Intenção: Extrair um grafo de fluxo a partir de diagramas de sequência e desenvolver casos de teste que provêem um mínimo de cobertura de caminhos.

• Modelo de Faltas: Faltas potenciais que podem ser encontradas com a utilização deste padrão para a geração de casos de teste são: saída faltando ou incorreta; falta de função/atributo em um participante; mensagem correta passada a um objeto errado; mensagem incorreta passada a um objeto certo; mensagem enviada a um objeto destruído; etc.

• Identificação: O código 3.1 apresenta uma instância do meta-modelo

TestPatternMetamodel, representada no formato XMI (XML Metadata Interchang) [39], para este padrão. Nele, é possível perceber quais os elemento(s) do meta-modelo de UML deve(m) ser investigado(s) nos modelos para a aplicação do padrão. De acordo com a especificação do padrão, para que seja possível sua aplicação, basta que dentre os modelos exista um diagrama de sequência. Dessa forma, o elemento do meta-modelo de UML a ser casado é Collaboration, uma vez que tal elemento é a representação de um diagrama de sequência em modelos UML. Contudo, como o interesse é gerar casos de teste que envolvam a classe que deseja-se integrar, é preciso que a classe estereotipada como ClassToBeIntegrated faça parte do diagrama. Essa restrição pode ser visualizada pelo elemento (patternConstraint).

3.3 Identificação da Aplicação de Padrões de Teste 39

Código Fonte 3.1: Elementos que identificam a aplicação do padrão Round-trip

Scenario Testde acordo com o meta-modelo TestPatternMetamodel.

1 < ? xml v e r s i o n ="1.0" e n c o d i n g ="UTF-8"? >

2 < t p m : M o d e l x m l n s : x m i ="http://www.omg.org/XMI" x m l n s : t p m ="TestPatternMetamodel">

3 < t e s t P a t t e r n name="Round Trip Scenario Test">

4 < i n t y p e ="Collaboration">

5 < p a t t e r n C o n s t r a i n t >

6 < s p e c i f i c a t i o n t y p e ="tpm:OpaqueExpression"

7 body ="context Collaboration inv:

8 self.ownedBehavior->first().ownedAttribute->

9 exists(att | att.type.getAppliedStereotypes()->

10 exists(a | a.name = ’ClassToBeIntegrated’));"

11 l a n g u a g e ="OCL 2.0" / >

12 < / p a t t e r n C o n s t r a i n t > 13 < i n / >

14 < / t e s t P a t t e r n >

15 < / t p m : M o d e l >

• Estratégia: O procedimento para a geração de casos de teste para esse padrão consiste nos seguintes passos:

1. Transformar o diagrama de sequência em um grafo de fluxo. Este grafo

é construído a partir da identificação de condições, segmentos e ramos, representados por retângulos, hexágonos e setas que levam a um hexágono, respectivamente. A Figura 3.7(b) mostra um grafo de fluxo extraído a partir do diagrama de sequência mostrado na Figura 3.7(a). Cada mensagem ou grupo de mensagens consecutivas, no diagrama de sequência, tornam-se segmentos, e cada condição em um fragmento combinado (opt, alt, loop, etc.) torna-se uma decisão (hexágono);

2. Identificar caminhos a partir do grafo de fluxo. Cada caminho será equivalente a um cenário para a geração dos casos de teste. Qualquer cenário irá atingir todos os segmentos no grafo se ele não tiver decisões. Contudo, no caso do grafo ter várias decisões, o número de caminhos pode ser muito grande. Logo, é preciso selecionar os caminhos de acordo com um mínimo de cobertura de decisão; 3. Identificar casos especiais. Em outras palavras, selecionar caminhos onde os

3.3 Identificação da Aplicação de Padrões de Teste 40

4. Identificar entradas e estados necessários para a execução dos caminhos.

No contexto de geração de casos de teste no nível de modelos, ou seja, modelos de teste independentes de plataforma, apenas os passos 1 e 2 devem ser realizados. Após a realização desses passos, os casos de teste devem ser construídos para cada caminho identificado. Como o passo 3 consiste em estratégias de seleção de casos de teste, ou seja, a seleção dos casos de teste que serão executados, e o passo 4 consiste na escolha de dados para a execução dos casos de teste, eles só precisam ser realizados em nível específico de plataforma e código.

• Exemplos: Considerando o diagrama de sequência Remove Object mostrado na Figura 3.7(a), seguindo a estratégia do padrão, descrita anteriormente, ele foi transformado em um grafo de fluxo, conforme mostrado na Figura 3.7(b) (passo 1).

Figura 3.7: (a) Diagrama de sequência Remove Object, e (b) seu grafo de fluxo

correspondente.

Uma vez construído o grafo de fluxo, três caminhos (cenários round-trip) foram identificados, conforme mostrado na Figura 3.8 (passo 2). De acordo com a estratégia do padrão, para cada um dos caminhos identificados, existe pelo menos um caso de teste associado. Nesse contexto, foi criado um caso de teste para cada caminho identificado conforme mostrado na Figura 3.9 (na mesma ordem de apresentação). Estes casos de teste, em nível de modelos, foram documentados de acordo com U2TP.

3.3 Identificação da Aplicação de Padrões de Teste 41

Figura 3.8: Caminhos para o diagrama de sequência Remove Object, sem loops ou condições, gerados a partir do grafo de fluxo.

Figura 3.9: Casos de teste gerados para o diagrama de sequência Remove Object,

documentados de acordo com U2TP e aplicando o padrão.

É importante ressaltar que, para cada cenário descrito, as condições em cada hexágono de decisão, passam a ser as pré-condições, e, consequentemente, algumas entradas do caso de teste. Os resultados esperados do caso de teste consistem na sequência de mensagens executada exatamente como descrito pelo diagrama de sequência que o representa e na «ValidationAction» no final do caso de teste, que corresponde ao veredito do caso de teste.

• Padrões Relacionados: Outros padrões podem ser utilizados para a seleção dos casos de teste gerados após a aplicação desse padrão. São exemplos: Extended Use Case