definição de uma heurística que identifica um elemento como root dos tabs se seguir um dos seguintes aspetos:
• A sua classe é do tipo “HorizontalScrollView” ou “TabWidget”;
• A sua classe é do tipo “LinearLayout” ou “FrameLayout” e possui as seguintes característi- cas:
– Tem pelo menos um descendente direto; – Não ocupa a totalidade do ecrã;
– Começa no lado esquerdo do ecrã e termina no seu lado direito; – O limite inferior corresponde à altura do dispositivo;
– Ocupa no máximo 15% da altura do dispositivo;
– Em nenhum dos seus elementos ascendentes é possível fazer scroll. 4.5.2 Diferença entre elemento e widget
Na comparação de ecrãs existe o conceito de widget sendo que, por esta razão, se torna im- portante definir a diferença entre um elemento e um widget. A definição de widget usada nesta dissertação tem por base a definição que já se encontrava implementada na iMPAcT tool [53]. As- sim, um elemento é um componente básico pertencente à estrutura do ecrã no qual pode ou não ser possível interagir (click, long click, etc). Por outro lado, um widget é um elemento visível, como um botão, texto ou imagem, ou um elemento de estrutura, como um Layout no qual é possível interagir.
4.6
Permissões do sistema
De acordo com a documentação do Android [24], as permissões do sistema podem ser dividi- das em dois tipos:
• Permissões normais – são permissões concedidas automaticamente pelo sistema que não colocam em risco a privacidade do utilizador da aplicação nem o normal funcionamento do dispositivo. A conexão à internet, a utilização do bluetooth e a criação de atalhos no launcherdo dispositivo são exemplos deste tipo de permissões.
• Permissões perigosas – devem ser concedidas explicitamente pelo utilizador. Ao contrá- rio das anteriores, este tipo de permissão pode potencialmente por em risco a privacidade do utilizador e o funcionamento do dispositivo. A leitura e escrita para o armazenamento externo, o acesso à câmara e a gravação de áudio são exemplos de permissões perigosas. Se o dispositivo estiver a executar o Android 5.1.1 ou inferior, ou a targetSdkVersion (nível máximo da API para o qual a aplicação será distribuída) da aplicação for 22 ou inferior, as per- missões perigosas necessárias são pedidas em tempo de instalação. Caso as permissões não sejam
44 Exploração dinâmica
aceites, a aplicação não é instalada. Se o dispositivo estiver a executar a versão 6.0 ou superior do Android e a targetSdkVersion da aplicação for 23 ou superior, a aplicação deve pedir ao utilizador para lhe conceder as permissões perigosas em tempo de execução.
Por esta razão, durante o processo de exploração da aplicação podem surgir diálogos de sis- tema para que o utilizador conceda permissão ao uso de determinado recurso. Se a permissão não for concedida, a exploração pode falhar ao explorar certas partes da aplicação para o qual não tem acesso. Existe a necessidade, portanto, que durante a exploração sejam aceites as permissões pedidas.
A identificação de um ecrã de pedido de permissão é feita verificando se o package name lido pela framework UI Automator é "com.android.packageinstaller". Este package name foi confir- mado através da execução de um conjunto de aplicações Android que necessitavam de permissões perigosas. A Figura4.3ilustra um ecrã com um pedido de permissão ao utilizador.
Figura 4.3: Pedido de permissão para gravar áudio
No caso de estarmos na presença de um ecrã de pedido de permissão, o botão “Allow”, presente no diálogo, é clicado e a exploração da aplicação prossegue.
4.7
Deteção de crashes
Tal como nos outros modos de exploração já existentes na iMPAcT tool, a deteção de crashes é feita verificando se o ecrã atual é um pop-up e se o seu package name é “android”. Nesses modos já existentes, sempre que surgia um crash na aplicação, o botão “Ok” era clicado. No entanto, com
4.8 Ficheiro de configuração 45
base em testes feitos a dispositivos executando diferentes versões do Android, é possível verificar que existem vários tipos de ecrãs que representam crashes. A Figura4.4ilustra esta situação.
Quando um crash é detetado, existem três ações que podem realizadas dependendo do tipo de ecrã:
• Se existir um botão com o texto “Ok”, este é clicado e a aplicação reiniciada;
• Se o botão anterior não existir, é verificado se o botão “Close app” existe e, em caso afirma- tivo, este é clicado. Após o clique, a aplicação é reiniciada;
• Se nenhum dos botões anteriores existir, é feito o clique no botão “Open app again”.
(a) Crash no Android 6.0 (b) Crash no Android 7.0 Figura 4.4: Exemplo de diferentes ecrãs de crash
4.8
Ficheiro de configuração
De forma a auxiliar o processo de exploração, o utilizador pode definir alguns dados num ficheiro de configuração. Estes dados são divididos em dois tipos:
• Dados da exploração – informação para o algoritmo de exploração que inclui: a) tempo máximo de exploração, de forma a limitar o tempo total da execução; b) número máximo de adições a um ecrã (limite superior), para evitar que a exploração fique presa num ecrã com um número infinito de eventos; c) prioridade, que indica se a exploração deve ser feita com ou sem prioridade de eventos.
46 Exploração dinâmica
• Dados de input – contém os vários tipos de input detetáveis pelo algoritmo (p. ex. pas- sword) associados a elementos EditText e o valor que o utilizador pretende que seja inserido associado a cada tipo.
Caso o utilizador não forneça o ficheiro de configuração ou se alguma informação estiver em falta neste ficheiro, a ferramenta irá usar os valores padrão pré-estabelecidos.
4.9
Script de execução
Durante a execução do processo de exploração, podem ser identificados problemas na apli- cação móvel em teste, tais como crashes ou outro tipo de comportamento não esperado. Após a correção destes erros, os passos da exploração realizada anteriormente devem ser feitos nova- mente de forma a verificar se estes problemas ainda existem. Por esta razão, há uma necessidade de existir um script para cada exploração realizada que contenha os eventos executados ordenados cronologicamente e que irão guiar o processo de reprodução da exploração.
4.9.1 Modo de utilização
Para que o script seja criado, a checkbox “Record Exploration Script”, presente na interface da iMPAcT tool, deve ser selecionada. No fim da exploração, o ficheiro é criado na pasta da ferra- menta e inclui no seu nome o timestamp verificado no momento, de forma a distinguir diferentes explorações.
Por outro lado, para iniciar o processo de reprodução de um script já existente, o utilizador necessita de realizar os seguintes passos: 1) clicar na dropbox de escolha do tipo de exploração; 2) escolher o modo “REPEAT_SCRIPT”; 3) procurar o caminho para o script, clicando no botão “Search” que surgiu ao escolher o modo; 4) introduzir o package name da aplicação e selecionar o dispositivo onde se pretende fazer a reprodução; 5) iniciar o processo, clicando no botão “Run”. A Figura4.5ilustra um sumário desta sequência de passos.
4.9 Script de execução 47
O ficheiro criado no final de uma exploração, necessário para que a sua reprodução seja possí- vel, é do tipo json e contém três tipos de informação:
• package_name: Identifica a aplicação explorada. Esta informação é necessária para garantir que a reprodução da exploração está a ser feita na mesma aplicação;
• resolution: Resolução do dispositivo. Esta informação é indispensável porque a posição de um elemento no ecrã é usada na sua identificação. Assim, não é possível realizar a reprodução de um script num dispositivo com resolução diferente do utilizado inicialmente na exploração;
• execution_trace: Contém uma lista com informação sobre os eventos executados na explo- ração, ordenada cronologicamente. A informação presente em cada elemento desta lista ajuda a que o evento seja recriado, em tempo de execução, durante a reprodução. O action é uma informação obrigatória e designa a ação do evento (p. ex. click, long click, edit, entre outros). Todos os outros dados dependem do tipo de ação do evento. O element contém uma string que identifica o elemento na interface da aplicação (se for um evento de UI). O input_typeidentifica o tipo de input do elemento (se este for EditText). O values contém o valor introduzido no elemento (se a ação for edit).
De seguida, é possível visualizar a parte inicial de um script de execução criado durante uma exploração à aplicação “aMetro” num dispositivo com a resolução de 1794x1080.
1 { 2 "package_name": "org.ametro", 3 "resolution": "1794x1080", 4 "execution_trace": [ 5 { 6 "action": "click",
7 "element": "class:android.widget.EditText;id:org.ametro:id\/ search_src_text;content:;bounds:Rect(168, 87 − 966, 182)", 8 "input_type": "Text"
9 },
10 {
11 "action": "edit",
12 "element": "class:android.widget.EditText;id:org.ametro:id\/ search_src_text;content:;bounds:Rect(168, 87 − 966, 182)", 13 "input_type": "Text",
14 "values": "teste" 15 },
16 ... 17 }
48 Exploração dinâmica
4.9.2 Algoritmo de reprodução
O primeiro passo do algoritmo consiste em fazer a leitura do script, isto é, do ficheiro que contém a sequência de eventos executada numa exploração anterior. Após a leitura, o algoritmo entre numa fase iterativa que apenas termina quando pelo menos uma das condições de paragem se verifica. O processo iterativo da reprodução inicia por ler o ecrã atual da aplicação e, numa fase seguinte, verifica se o evento a reproduzir é um evento do sistema ou um evento associado a um elemento da interface. Se o evento for de sistema, este é criado para ser executado. Caso contrário, se o evento for de UI, é feita uma análise aos elementos existentes na estrutura do ecrã atual para verificar se o elemento associado ao evento a reproduzir existe no ecrã e, em caso afirmativo, o evento é criado.
Após a conclusão das etapas anteriores, se o evento tiver sido criado este é executado e a va- riável eventNumber, que controla o número de eventos executados, incrementada. Caso contrário, a variável waitedTimes, que controla o número de iterações de espera por um elemento, é incre- mentada e é esperado um certo tempo para que o ecrã acabe de carregar os possíveis elementos que ainda não surgiram.
A reprodução do script apenas pode ser terminada automaticamente, sendo que a variável que controla este processo é a finishExploration. Assim, a execução da reprodução pode terminar quando:
• A variável eventNumber possui o mesmo valor que o tamanho da lista de eventos do script, indicando que todos os eventos foram executados com sucesso;
• A variável waitedTimes atinge o número limite de tentativas de espera por um elemento que ainda não existe no ecrã. Esta condição foi criada para prevenir que a execução fique presa se o elemento associado ao evento a reproduzir não existir na interface da aplicação. Em cada iteração, se o elemento não existir, é esperado um tempo fixo para que o ecrã acabe de carregar e, posteriormente, a reprodução avança para uma nova iteração (sem incremen- tar a variável eventNumber). Caso o elemento não surja nas duas próximas iterações, a reprodução termina.
O Algoritmo 3apresenta o pseudocódigo implementado para a reprodução de um script de execução.
4.10
Conclusões
Neste capítulo foi apresentada uma nova abordagem de exploração desenvolvida como uma extensão da iMPAcT tool. Durante o processo de exploração, quando é detetado que todos os eventos do ecrã atual estão exercitados, o algoritmo de Dijkstra é executado de forma a encontrar o caminho de eventos mais curto entre ecrã atual e o próximo ecrã a ser explorado (primeiro ecrã presente na lista ainda não marcado como explorado).
Como mencionado no Capítulo 1, existem vários desafios que podem fazer com que uma exploração dinâmica falhe a explorar totalmente uma aplicação. Entre estes desafios salientam-se:
4.10 Conclusões 49
Algoritmo 3 Reprodução do script de execução 1: traceEvents← readExecutionTraceFile() 2: eventNumber← 0 3: f inishExploration← false 4: waitedTimes← 0 5: while ! f inishExploration do 6: currentScreen← readScreen()
7: eventIn f ormation← traceEvents.get(eventNumber) 8: if isSystemEvent(eventIn f ormation) then
9: event← createSystemEvent(eventIn f ormation)
10: else
11: elements← currentScreen.getElements() . Obter todos os elementos do ecrã atual 12: for i ← 0 to elements.size() do
13: element← elements.get(i)
14: if eventIn f ormation.get(“element”) = element then . Se o elemento existe 15: event← createElementEvent(element, eventIn f ormation)
16: break
17: end if
18: end for
19: end if 20: if event then
21: if executeEvent(event) then . Se o evento foi corretamente executado 22: eventNumber← eventNumber + 1
23: waitedTimes← 0
24: end if
25: else
26: waitedTimes← waitedTimes + 1
27: waitForStableScreen() . Esperar um tempo fixo para que o ecrã termine de carregar 28: end if
29: if eventNumber = traceEvents.size() or waitedTimes = 3 then 30: f inishExploration← true
31: end if 32: end while
• Pontos de bloqueio;
• Introdução de novos gestos de interação; • Identificação de ecrãs diferentes;
• Comportamento dinâmico das aplicações móveis.
Relativamente ao primeiro desafio, o algoritmo implementado consegue detetar o tipo de input dos elementos EditText. Além disto, o utilizador pode indicar num ficheiro de configuração o valor que pretende que seja inserido associado a cada tipo de input. Desta forma, caso sejam detetados elementos EditText do tipo email, password, text, entre outros, o valor associado presente no ficheiro de configuração é usado.
50 Exploração dinâmica
Para o segundo desafio, foram implementados novos gestos de interação ainda não existentes na ferramenta, tais como o swipe, pinch e drag. Além do mais, o algoritmo é totalmente extensível permitindo a inclusão de novos eventos que possam surgir no futuro.
Em relação ao terceiro desafio, foi implementada uma nova heurística de comparação de ecrãs que visa tentar distinguir ecrãs diferentes, ao contrário da heurística que já existia na iMPAcT tool que tenta distinguir atividades diferentes.
Para o último desafio, de forma a evitar que a exploração fique presa num ecrã se novos elementos surgirem sempre que se executa um evento, foi definido um número máximo de vezes no qual podem ser adicionados novos elementos à estrutura de um ecrã. Além disto, para tentar executar o maior número de eventos possível, um evento já executado pode voltar a ser considerado para execução se os eventos a que deu origem no mesmo ecrã ainda não estão todos exercitados.
De forma a validar o algoritmo de exploração implementado, foram realizadas várias experiên- cias com aplicações disponíveis na loja oficial da Google. Estas experiências e os seus resultados podem ser encontrados no próximo capítulo.
Capítulo 5
Experiências
Este capítulo tem como principal objetivo apresentar os resultados das experiências realizadas para validar o algoritmo de exploração implementado como uma extensão da iMPAcT tool. Nestas experiências, os dois modos de exploração associados ao novo algoritmo são considerados dois algoritmos distintos e a análise de cobertura de código é feita ao nível da instrução.
Este capítulo está estruturado da seguinte forma. A Secção 5.1 apresenta as especificações técnicas do emulador e dos computadores usados nas experiências. A Secção 5.2 apresenta e descreve a metodologia de teste definida. Os resultados das experiências realizadas encontram-se nas Secções5.3e5.4. A Secção5.5contém as respostas às questões de investigação. Finalmente, as conclusões deste capítulo são apresentadas na Secção5.6.
5.1
Especificações técnicas
Todas as experiências apresentadas neste capítulo para validar a abordagem implementada foram realizadas em dois computadores executando um emulador Android com as mesmas es- pecificações. Foram utilizados dois computadores de maneira a diminuir para metade o tempo total das experiências realizadas. As principais especificações técnicas dos computadores são as seguintes:
Computador portátil Asus ROG GL552VW • Sistema operativo: Windows 10
• RAM: 8 GB
• CPU: Intel CoreR TMi5-6300HQ • GPU: NVIDIA GeForce GTX 960M • Chipset: Intel HM170R
52 Experiências
Computador fixo personalizado • Sistema operativo: Windows 10 • RAM: 8 GB
• CPU: Intel CoreR TMi5-4690K • GPU: NVIDIA GeForce GTX 960 • Chipset: Intel B85R
As principais especificações do emulador que foi executado nos computadores previamente indicados são as seguintes:
Nexus 5X
• Sistema operativo: Android 6.0 • RAM: 2 GB
• Número de núcleos do CPU: 2 • Gráficos: Hardware - GLES 2.0
5.2
Metodologia de teste
Para garantir que os resultados obtidos nas experiências são fiáveis, é importante definir uma metodologia de teste correta. Por esta razão, a metodologia definida tem em conta a aleatoriedade da escolha do evento a executar e a existência de outros algoritmos e ferramentas de exploração dinâmica. Esta metodologia é constituída pelas seguintes fases:
1. Seleção das aplicações móveis Android às quais serão feitas as explorações;
2. Análise e escolha de um pequeno conjunto de ferramentas de exploração dinâmica disponí- veis no estado da arte;
3. Instrumentação das aplicações móveis selecionadas de forma a ser possível obter resultados de cobertura de código. Este acesso ao código fonte da aplicação é feito apenas para validar a abordagem desenvolvida;
4. Execução da exploração em cada uma das aplicações selecionadas usando os algoritmos implementados e as ferramentas escolhidas para comparação;
5. Recolha dos resultados de cobertura e tempo de execução das explorações; 6. Comparação dos resultados obtidos por cada uma das ferramentas;
5.2 Metodologia de teste 53
5.2.1 Seleção do conjunto de aplicações
A primeira fase da metodologia de teste consistiu em fazer uma seleção consistente, mas ao mesmo tempo diversificada de aplicações Android. Para que isto fosse possível, as aplicações foram selecionadas de várias categorias disponíveis na Google Play Store garantindo assim que possuíam diferentes características. Para além disto, existiam outros requisitos que cada aplicação tinha de cumprir de maneira a ser escolhida para as experiências:
• Ser compatível com os dispositivos especificados; • Ser uma aplicação nativa;
• Não depender de outras aplicações para ser executada; • Possível de ser lida pelo UI Automator;
• Estar disponível na Google Play Store e ser gratuita; • Ter pelo menos 10.000 transferências;
• Ter pelo menos 4.0 como classificação na loja; • Ser open source;
• Usar Gradle para simplificar a sua build; • Ser puramente escrita em Java;
• Ter como idioma uma linguagem da Europa Ocidental.
O conjunto final de aplicações selecionadas encontra-se disponível na Tabela5.1.
Tanto no algoritmo de exploração implementado como nos já existentes na iMPAcT tool, existe um fator de aleatoriedade associado à escolha do evento a executar que pode influenciar os resulta- dos das experiências. Assim, de forma a obter resultados mais fiáveis, cada aplicação foi explorada três vezes por cada algoritmo de exploração usado, sendo que os resultados apresentados neste ca- pítulo são a média dos resultados dessas execuções.
5.2.2 Ferramentas de exploração
Para validar a abordagem implementada, torna-se importante comparar os resultados obtidos na sua execução com os resultados de outras ferramentas de exploração existentes no estado da arte. Relativamente à cobertura de código, esta comparação apenas pode ser considerada válida se for usado o mesmo método que reporta este tipo de cobertura nas execuções de todas as fer- ramentas. As seguintes ferramentas foram analisadas para verificar se era possível executá-las: Dynodroid, PUMA, AndroidRipper, Monkey e iMPAcT tool (algoritmo de exploração já exis- tente).
54 Experiências
Tabela 5.1: Conjunto final de aplicações selecionadas
Aplicação Versão Categoria Número de
instruções
aMetro 2.0.1.6 Mapas e navegação 19.681
Chroma Doze 3.7.1 Música e áudio 23.780
Debatekeeper 1.3-dev Utilitários 15.868
Easy xkcd 7.3.2 Banda desenhada 28.483
Omni Notes 6.0.0 Beta 9 Produtividade 38.325
RedReader 1.9.10 Notícias e revistas 77.918
RGB Tool 2.0.0-SNAPSHOT Utilitários 11.114
Sound Recorder 1.3.0 Utilitários 3.204
Timber Music Player 1.6-debug Música e áudio 55.480
Unit Converter Ultimate 5.4 Utilitários 5.967
No entanto, apenas o Monkey e o algoritmo já existente na iMPAcT tool foram usados na com- paração, visto que todas as outras ferramentas apresentaram problemas. Os links disponíveis para downloaddo Dynodroid já não se encontram válidos. O PUMA falhava no início do processo de execução, informando que um ficheiro estava em falta no diretório. Por último, o AndroidRipper formatava o emulador no final do seu processo de exploração, fazendo com que os resultados de cobertura de código fossem apagados.
Relativamente ao algoritmo já existente na iMPAcT tool, foi escolhido o Priority to not exe- cuted and list items porque, segundo o autor, este proporciona uma exploração mais completa identificando mais eventos e executando uma maior percentagem de eventos [50].
5.2.3 Ferramenta de análise de cobertura de código
Existem várias ferramentas para análise de cobertura de código a testes caixa branca e a caixa preta, como verificado na revisão literária apresentada no Capítulo2. No entanto, muitas das fer- ramentas de análise a testes caixa preta não se encontram disponíveis para uso. Relativamente à análise de cobertura a testes caixa branca, o Emma foi excluído das opções pois já não é atualizado desde 2005. Por estas razões, a escolha da ferramenta de análise de cobertura de código ficou li- mitada a duas opções, o ACVTool e o JaCoCo. A Tabela5.2apresenta as principais características destas duas tecnologias que influenciaram a escolha final.
Tabela 5.2: Características do ACVTool e do JaCoCo
Características ACVTool JaCoCo
Após surgir um crash na aplicação, a cobertura de
código continua a ser acumulada X
Acumula cobertura de várias execuções da