Como já foi referido, o objetivo da ferramenta é verificar se os UI Patterns, encontrados du- rante a exploração da aplicação Android, estão corretamente implementados. Para isto, caso seja encontrado um UI Pattern este é testado usando a estratégia de teste associada. Desta forma, a definição do catálogo de padrões é uma das partes mais importantes de toda a abordagem. Este catálogo apenas necessita de ser definido uma vez e é composto por um conjunto de UI Patterns que se pretendem identificar e pelas estratégias de teste correspondentes [49].
Tanto o UI Pattern como os Test Patterns associados podem ser formalmente definidos como um conjunto de tuplos <Objetivo, V, A, C, P> nos quais [50]:
• Objetivo é o ID do padrão;
• V é um conjunto de pares que incluem uma variável e um valor e que relaciona os dados fornecidos com as variáveis envolvidas;
• A é a sequência de ações a executar; • C é o conjunto de verificações a realizar;
• P é a pré-condição booleana que define as condições nas quais o padrão deve ser aplicado. Para um padrão ser aplicado, o utilizador da ferramenta deve fornecer o valor para cada va- riável em V. Após esta etapa, aplicar um padrão consiste em analisar se a pré-condição (P) é
3.2 Catálogo de padrões 27
verdadeira, e em caso afirmativo executar uma sequência de ações (A) utilizando os valores for- necidos na configuração (V). No fim desta execução são realizadas um conjunto de verificações (C).
Relativamente à identificação de um UI Pattern, a pré-condição (P) fornece informação sobre se a ferramenta deve ou não tentar identificar este padrão, enquanto que as verificações finais (C) indicam se o padrão foi ou não encontrado. Por outro lado, ao aplicar um Test Pattern a pré- condição (P) fornece informação sobre se a estratégia de teste deve ser aplicada, enquanto que as verificações finais (C) indicam se o teste passou ou não, ou seja, fornecem informação sobre se o UI Patterncorrespondente está ou não bem implementado.
Os padrões que estão presentes atualmente no catálogo da ferramenta são os seguintes: padrão side drawer, padrão de orientação, padrão de dependência de recursos, padrão de background [59], padrão de back, padrão de up, padrão de action bar, padrão de tabs e padrão de chamadas [57]. Estes padrões têm por base as diretrizes fornecidas pela Google de como desenvolver e testar aplicações móveis Android [23]. De seguida, serão apresentados os três primeiros padrões da lista anterior.
3.2.1 Padrão side drawer
O Side Drawer (também conhecido como Navigation Drawer) é um menu que mostra as principais opções de navegação da aplicação no lado esquerdo do ecrã. Este menu apenas é visível quando o utilizador da aplicação desliza o dedo a partir do lado esquerdo do ecrã (swipe) ou quando clica no ícone da aplicação no lado esquerdo da Action Bar. A Figura3.2ilustra um exemplo deste padrão.
O UI Pattern responsável por identificar a presença deste menu numa interface da aplicação é definido como [49,53]:
• Objetivo: “Existe um Side Drawer” • V: {}
• A: [Ler o ecrã]
• C: {“O Side Drawer existe e não está visível”} • P: {Verdadeiro}
O Test Pattern correspondente, responsável por verificar se o UI Pattern ocupa toda a altura do ecrã é definido como [49,53]:
• Objetivo: “Side Drawer ocupa toda a altura do ecrã” • V: {}
28 iMPAcT tool
Figura 3.2: Exemplo do padrão Side Drawer [22]
• C: {“O Side Drawer ocupa a altura toda do ecrã”}
• P: {“UI Pattern está presente && Side Drawer está disponível && Test Pattern não foi aplicado na atividade atual”}
3.2.2 Padrão de orientação
Quando existe rotação de um dispositivo móvel, a interface da aplicação aberta nesse momento atualiza a disposição dos seus elementos para se ajustar a esta mudança. No entanto, a adaptação do layout apenas é possível se não existir bloqueio da orientação no manifesto da aplicação para a respetiva atividade. Este padrão é ilustrado na Figura3.3.
Com tudo isto, os desenvolvedores de aplicações devem ter especial atenção para dois aspetos presentes nas diretrizes fornecidas pela Google [23]:
• Não deve ser perdido nenhum input do utilizador após a rotação do ecrã; • Os widgets não devem desaparecer durante a rotação do ecrã.
Diversos estudos já foram feitos sobre os motivos de a orientação interferir com uma aplicação móvel. Amalfitano et al. [5] testaram manualmente aplicações móveis usando double orientation change(DOC) que consiste na sequência de duas mudanças consecutivas de orientação. Nos testes realizados neste estudo, foi utilizado DOC porque aplicar apenas uma mudança de orientação podia não ser suficiente para detetar falhas na interface do utilizador, visto que são aceitáveis
3.2 Catálogo de padrões 29
algumas diferenças entre as duas orientações possíveis. Após a segunda rotação, o layout e o conteúdo da interface devem ser iguais ao estado inicial da aplicação, antes da primeira rotação, de forma a não existir uma falha na GUI.
Figura 3.3: Exemplo do padrão de Orientação. a) portrait e b) landscap [55]
O UI Pattern que verifica se é possível realizar a rotação do ecrã é definido como [49,53]: • Objetivo: “Rotação é possível”
• V: {} • A: []
• C: {“É possível rodar o ecrã”} • P:{“Verdadeiro”}
Este padrão possui dois Test Patterns associados [53,49]. O primeiro é responsável por veri- ficar se os dados presentes no ecrã não são perdidos e é definido como:
• Objetivo: “Dados não alterados após a rotação do ecrã” • V: {}
• A: [Ler ecrã, rodar ecrã, ler ecrã, scroll do ecrã, ler ecrã] • C: {“Dados introduzidos pelo utilizador não foram perdidos”}
30 iMPAcT tool
• P: {“UI Pattern está presente && utilizador introduziu dados && Test Pattern não foi apli- cado na atividade atual”}
O segundo Test Pattern é responsável por verificar se não houve perda de elementos na inter- face. Este padrão é definido como:
• Objetivo: “Principais componentes da interface do utilizador continuam presentes” • V: {}
• A: [Ler ecrã, rodar ecrã, ler ecrã, scroll do ecrã, ler ecrã] • C: {“Principais componentes ainda estão presentes”}
• P: {“UI Pattern está presente && Test Pattern não foi aplicado na atividade atual”}
Aquando da rotação do ecrã, alguns elementos podem ser realocados em novas posições e, desta forma, desaparecerem da parte visível da interface. Por esta razão, a ferramenta efetua scroll ao ecrã para garantir o acesso total à árvore de elementos da interface.
3.2.3 Padrão de dependência de recursos
Uma aplicação móvel pode usufruir de recursos externos que o telemóvel possui e, assim, estar dependente da disponibilidade destes recursos. Exemplo destes recursos são o Wi-Fi, o NFC, o Bluetoothe o GPS. Torna-se importante, desta forma, verificar se a aplicação não têm problemas quando estes recursos não estão disponíveis para utilização [23].
O UI Pattern que verifica se o recurso configurado está a ser utilizado pela aplicação móvel em teste é definido como [49,53]:
• Objetivo: “Recurso está em uso” • V: {“resource”, nome_do_recurso} • A: [Ler estado do recurso]
• C: {“Recurso a ser utilizado pela aplicação”} • P: {“Verdadeiro”}
O Test Pattern associado, responsável por verificar se a aplicação móvel não falha quando o recurso fica indisponível, é definido como [49,53]:
• Objetivo: “A aplicação não falha quando o recurso fica indisponível” • V: {“resource”, nome_do_recurso}
• A: [Ler ecrã, desativar o recurso, ler ecrã] • C: {“Aplicação não falhou”}