Mecanismo Único de Teste

Essa etapa estabelece um mecanismo adequado para teste automatizado de UI em múltiplas configurações. Nesse caso, um script de teste comum entre diferentes plataformas. O caso de teste representado pelo ESG (Figura 15) é base para sua construção, uma vez que cada evento sob teste contém dados sobre um elemento de UI, assim como as expressões de consulta capazes de selecioná-lo.

O Algoritmo 1 apresenta um pseudocódigo do script para a execução das seis expressões individuais. O método Exec (Linha 2) recebe por parâmetro as expressões de consulta XPath, uma para cada plataforma, além da plataforma alvo da execução corrente. O método localiza um elemento na estrutura XML da UI da aplicação utilizando as expressões (Linha 8). Ao final, o elemento encontrado é executado de acordo com a ação indicada pelo testador (Linha 12). Quando o elemento não é encontrado uma exceção é lançada para falhar a execução do caso de teste (Linhas 9-10). Estruturas lógicas condicionais conduzem o fluxo do scriptpara atender a cada plataforma (Linhas 3-7).

Como as expressões individuais anteriormente mencionadas podem ser limitadas em alguns contextos, são propostas duas novas estratégias de localização que combinam as seis expressões, ExpressionsInOrder e ExpressionsMultiLocator, apresentadas a seguir.

ExpressionsInOrder: Para selecionar o elemento vinculado ao evento, as expressões são

Algoritmo 1 Pseudocódigo - Execução das expressões individuais.

1: Input

xPathSelectorAndroid- Seletor de elemento para Android xPathSelectorIOS- Seletor de elemento para iOS plat f orm- Nome da plataforma sob teste

2: procedure EXEC(xPathSelectorAndroid, xPathSelectorIOS, plat f orm)

3: if plat f orm = "Android" then

4: xPathSelector= xPathSelectorAndroid;

5: else if plat f orm = "iOS" then

6: xPathSelector= xPathSelectorIOS;

7: end if

8: e= FindElementByXPath(xPathSelector);

9: if e == null then

10: throw new exception("Element not found");

11: else

12: e.action();

13: end if

14: end procedure

próxima é executada, e assim sucessivamente. O objetivo é garantir que o elemento seja localizado para não interromper a execução do caso de teste quando um elemento não é encontrado. A ordem definida para execução das expressões dá prioridade para expressões relativas, iniciando pela expressão CrossPlatform devido sua adequação para selecionar elementos de UI no Android e no iOS. Alguns estudos (LEOTTA et al., 2015, 2014; RAO; PACHUNOORI, 2013) sugerem fragilidades na localização de elementos por expressões absolutas, sendo assim, estão (AncestorIndex e AbsolutePath) ao final da lista. A sequência definida para execução foi:

1◦ CrossPlatform; 2◦ ElementType; 3◦ IdentifyAttributes; 4◦ AncestorAttributes; 5◦ AncestorIndex; 6◦ AbsolutePath.

O Algoritmo 2 apresenta um pseudocódigo para a estratégia proposta. O método

ExecInOrder (Linha 2) recebe como parâmetro um conjunto de seis expressões XPath

ordenadas, e localiza um elemento dentro da estrutura XML da UI da aplicação usando as expressões (Linhas 9-14). Ao final, o elemento encontrado (por alguma das expressões) é executado de acordo com a ação indicada pelo testador (Linha 18). Quando um elemento não é encontrado, uma exceção é lançada para falhar o caso de teste (Linhas 15-16). Estruturas condicionais direcionam o fluxo do evento para atender a cada plataforma.

Algoritmo 2 Pseudocódigo - Execução ExpressionsInOrder

1: Input

xPathCrossPlat f orm- Seletor multiplataforma de elemento (CrossPlatform)

xPathsAndroid[] - Seletores de Elemento para Android (AbsolutePath, IdentityAttributes, CrossPlatform, ElementType, AncestorIndex e AncestorAttributes)

xPathsiOS[] - Seletores de Elemento para iOS (AbsolutePath, IdentityAttributes, CrossPlatform, ElementType, AncestorIndex e AncestorAttributes)

plat f orm- Nome da plataforma sob teste

2: procedure EXECINORDER(xPathCrossPlat f orm, xPathsAndroid[], xPathsiOS[], plat f orm)

3: xPathSelectors[] = xPathCrossPlat f orm;

4: if plat f orm = "Android" then

5: xPathSelectors[] += xPathsAndroid;

6: else if plat f orm = "iOS" then

7: xPathSelectors[] += xPathsiOS;

8: end if

9: for each selector in xPathSelectors[] do

10: e= FindElementByXPath(selector); 11: if e != null then 12: break; 13: end if 14: end for 15: if e == null then

16: throw new exception("Element not found");

17: else

18: e.action();

19: end if

20: end procedure

ExpressionsMultiLocator: Nessa estratégia, todas as expressões são executadas e o elemento

é selecionado a partir de critérios de votação. Tais critérios foram propostos baseados

em estratégias de confiabilidade para determinar pesos para cada tipo de expressão. Essa abordagem foi adaptada de LEOTTA et al. (2015), a qual é empregada no teste de aplicações Web. A seguir são discutidos e apresentados os critérios de definição de pesos. A Tabela 6 foi adaptada a partir do estudo citado anteriormente e relaciona os pesos normalizados entre 0 e 1 definidos para cada expressão.

• As expressões de consulta baseadas em valores de atributos chave (visualizados na UI) possuem peso alto, devido a constância em manter seus valores e não dependem de índices e/ou caminho absoluto para sua localização. Exemplos desses atributos são o content-desc, text, label e value. As expressões contidas nesse grupo são: ElementType,

CrossPlatforme AncestorAttributes;

• As expressões de consulta baseadas em valores de atributos identificadores, tais como

resource-id (Android) e name (iOS) têm peso médio. Em alguns frameworks de

desenvolvimento de aplicações, os valores dos atributos identificadores de elementos sofrem alterações durante as diferentes execuções, dessa forma a confiabilidade na seleção é comprometida. Um exemplo desse tipo de expressão é a IdentifyAttributes;

• As expressões de consulta baseadas em caminhos absolutos ou que utilizam índices (posicionamento) têm peso pequeno. Possui uma confiança baixa, devido sua fragilidade em manter-se consistente após a evolução da aplicação (LEOTTA et al., 2015, 2014;

RAO; PACHUNOORI, 2013) ou quando o conteúdo é dinâmico. Exemplos dessas

expressões são: AbsolutePath e AncestorIndex.

Tabela 6: Tipos de expressões e pesos.

Tipos de Expressão Confiabilidade Peso

CrossPlatform Alta 0,25 ElementType Alta 0,25 AncestorAttributes Alta 0,25 IdentifyAttributes Média 0,15 AbsolutePath Baixa 0,05 AncestorIndex Baixa 0,05

O Algoritmo 3 apresenta um pseudocódigo para a estratégia ExpressionsMultiLocator. Tal como na estratégia combinada anterior, o método ExecMultiLocator (Linha 2) recebe como parâmetro um conjunto de seis expressões de consulta. Mas nesse caso, todas as expressões são executadas e para cada elemento encontrado seu peso é extraído de acordo com o tipo da expressão corrente. Um mesmo elemento retornado por diferentes expressões tem seu peso acumulado. Ao final, o elemento com maior votação (somatório dos pesos) é usado na execução do caso de teste (Linhas 24-25). Quando um elemento não é encontrado uma exceção é lançada para falhar a execução do caso de teste (Linhas 21-22). Nessa primeira versão da estratégia não foi implementado critérios de desempate quando elementos diferentes obtêm o mesmo peso, sendo assim, o primeiro elemento contido na estrutura de dados é selecionado para o teste.