Exploração Dinâmica em Android

F

E

U

P

Exploração Dinâmica em Android

Jorge Miguel Rodrigues Ferreira

Mestrado Integrado em Engenharia Informática e Computação Orientador: Ana Cristina Ramada Paiva

Exploração Dinâmica em Android

Jorge Miguel Rodrigues Ferreira

Mestrado Integrado em Engenharia Informática e Computação

Aprovado em provas públicas pelo Júri:

Presidente: João Carlos Pascoal Faria

Arguente: João Alexandre Baptista Vieira Saraiva Vogal: Ana Cristina Ramada Paiva

Resumo

Vivemos numa altura onde os smartphones são indispensáveis para o nosso dia a dia. De facto, com a evolução destes dispositivos e com as facilidades dadas aos desenvolvedores de aplicações, tem-se verificado uma rápida expansão do número de aplicações disponíveis para eles. Incluídas neste número estão aplicações críticas, tais como aplicações de pagamentos. Por estes motivos, é cada vez mais importante testar adequadamente estas aplicações. Contudo, o teste manual é com-plicado, uma vez que existem muitos dispositivos diferentes. Automatizar o teste de aplicações móveis torna-se, por isso, cada vez mais relevante.

Teste baseado em modelos é uma das técnicas para automatizar a geração de casos de teste a partir de um modelo. No entanto, esta técnica tem alguns problemas como, por exemplo, o processo moroso que é a criação manual do modelo. Para resolver este problema, uma das pos-síveis soluções é a existência de um processo engenharia reversa dinâmico sustentado por uma exploração da aplicação, que pode extrair parte do modelo para a técnica de teste baseado em modelos.

Existem abordagens dinâmicas para explorar aplicações móveis, mas estas abordagens pos-suem alguns desafios que necessitam de ser ultrapassados de forma a conseguirem obter bons resultados, tais como conseguir ultrapassar os pontos de bloqueio (p. ex. um sistema de auten-ticação), escolher os dados de input apropriados, testar o comportamento dinâmico da aplicação, executar os vários gestos de interação existentes, entre outros.

Este documento apresenta uma abordagem de exploração dinâmica de aplicações móveis An-droid que visa superar alguns dos problemas identificados. Durante o processo de exploração, o algoritmo constrói uma máquina de estados finita, onde cada estado representa um ecrã identifi-cado e as transições entre estes estados descrevem eventos que permitem a passagem de um ecrã para outro. Esta abordagem encontra-se implementada como uma extensão da iMPAcT tool.

De forma a validar o algoritmo implementado, foram realizadas duas experiências com aplica-ções reais disponíveis na Google Play Store. Nestas experiências foram analisadas a cobertura de código e de eventos para avaliar o desempenho do novo algoritmo. Após analisar estes resultados, foi possível verificar que o algoritmo desenvolvido apresenta melhor desempenho que outros dois algoritmos existentes no estado da arte.

Keywords: Exploração móvel, Exploração, Engenharia reversa, Exploração dinâmica, Teste de aplicações móveis

Abstract

We live in a time where smartphones are indispensable for our daily life. In fact, with the evolution of these devices, and with the facilities that are given to the developers of applications, a rapid expansion of the number of available applications for them is being verified. Included in this number are critical applications, such as payment applications. For these reasons, it is increasingly important to properly test these applications. However, manual testing is complicated since there are many different devices. Automating the testing of mobile applications becomes, therefore, increasingly relevant.

Model-Based Testing is one of the techniques to automate the generation of test cases from a model. However, this technique has some problems, such as the time-consuming process that is the manual creation of the model. To solve this problem, one of the possible solutions is the existence of a dynamic reverse engineering process that is sustained by an exploration of the application that can extract part of the model for the MBT technique.

There are dynamic approaches to explore mobile applications, but these approaches have some challenges that need to be overcome in order to achieve good results, such as overcoming blocking points (e. g. an authentication system), choosing appropriate input data, testing dynamic behaviour of the application, executing the different existing interaction gestures, among others.

This document presents a dynamic exploration approach of Android mobile applications that aims to overcome some of the identified problems. During the exploration process, the algorithm builds a Finite State Machine in which each state represents an identified screen and each transition between these states describes an event that allows moving from one screen to another. This approach is implemented as an extension of the iMPAcT tool.

In order to validate the implemented algorithm, two experiments were performed with real applications available on Google Play Store. In these experiments, code and event coverage were analysed to assess the performance of the new algorithm. After analysing these results, it was pos-sible to verify that the developed algorithm presents better performance than two other algorithms existent in the state of the art.

Keywords: Mobile exploration, Crawling, Reverse engineering, Dynamic exploration, Mobile testing

Agradecimentos

A elaboração desta dissertação de mestrado não seria possível sem o apoio, empenho e força de várias pessoas, às quais gostaria de deixar algumas palavras de agradecimento.

Em primeiro lugar, gostaria de agradecer à professora Ana Paiva, pela sua amizade, dedicação nesta orientação, disponibilidade sempre mostrada e pelos conhecimentos transmitidos ao longo do desenvolvimento do trabalho.

Gostaria também de agradecer aos alunos de doutoramento presentes no laboratório de enge-nharia de software, João Pedro e Bruno Lima, pelo conhecimento partilhado e por estarem sempre disponíveis para me esclarecerem as dúvidas que surgiram ao longo da dissertação.

E porque dizem que os amigos são a família que escolhemos, gostaria de agradecer a todos os meus amigos, por todas as palavras de incentivo durante esta jornada.

Por último, e porque sem eles nada disto era possível, gostaria de agradecer aos meus pais, Manuela Silva e António Ferreira, pelo seu amor, carinho e por estarem sempre ao meu lado, tanto nos bons como nos maus momentos. Obrigado por me terem tornado quem sou hoje.

Jorge Miguel Rodrigues Ferreira

“All our dreams can come true, if we have the courage to pursue them.”

Walt Disney

Conteúdo

2.1.1 Automatização de testes a aplicações móveis . . . 7

2.1.2 Testes de caixa branca e testes de caixa preta . . . 9

2.1.3 Ferramentas de suporte . . . 10

2.2 Teste baseado em modelos . . . 13

2.3 Engenharia reversa . . . 14 2.4 Cobertura . . . 15 2.5 Exploração dinâmica . . . 17 2.6 Conclusões . . . 21 3 iMPAcT tool 23 3.1 Abordagem . . . 23 3.1.1 Implementação . . . 23

3.1.2 Fases do processo iterativo . . . 24

3.1.3 Modos de exploração . . . 25

3.1.4 Condição de paragem . . . 26

3.2 Catálogo de padrões . . . 26

3.2.1 Padrão side drawer . . . 27

3.2.2 Padrão de orientação . . . 28

3.2.3 Padrão de dependência de recursos . . . 30

3.3 Artefactos . . . 31

3.3.1 Relatório da exploração . . . 31

3.3.2 Modelo do comportamento observado . . . 31

3.4 Contribuições da ferramenta para a comunidade . . . 32

3.5 Conclusões . . . 33 4 Exploração dinâmica 35 4.1 Algoritmo de exploração . . . 35 4.2 Condições de paragem . . . 39 4.3 Modos de exploração . . . 39 ix

x CONTEÚDO

4.4 Tipos de eventos suportados . . . 40

4.5 Critério de comparação de ecrãs . . . 40

4.5.1 Identificação do elemento tabs . . . 42

4.5.2 Diferença entre elemento e widget . . . 43

4.6 Permissões do sistema . . . 43 4.7 Deteção de crashes . . . 44 4.8 Ficheiro de configuração . . . 45 4.9 Scriptde execução . . . 46 4.9.1 Modo de utilização . . . 46 4.9.2 Algoritmo de reprodução . . . 48 4.10 Conclusões . . . 48 5 Experiências 51 5.1 Especificações técnicas . . . 51 5.2 Metodologia de teste . . . 52

5.2.1 Seleção do conjunto de aplicações . . . 53

5.2.2 Ferramentas de exploração . . . 53

5.2.3 Ferramenta de análise de cobertura de código . . . 54

5.3 Desempenho dos algoritmos de exploração . . . 55

5.3.1 Cobertura de eventos . . . 56

5.3.2 Cobertura de código . . . 58

5.4 Impacto do aumento do tempo máximo de exploração na cobertura da aplicação . 59 5.5 Discussão . . . 60

5.5.1 QI 1: É possível explorar automaticamente o comportamento das aplica-ções Android através de uma análise dinâmica? . . . 60

5.5.2 QI 2: É possível obter melhores resultados que outros algoritmos já exis-tentes no estado da arte? . . . 60

5.5.3 QI 3: É a cobertura de eventos diretamente proporcional à cobertura de código? . . . 61

5.5.4 QI 4: Qual o efeito de aumentar o tempo máximo da exploração na cober-tura da aplicação? . . . 61

5.6 Conclusões . . . 62

6 Conclusões e trabalho futuro 65 Referências 67 A Funções 73 A.1 Criação do evento edit . . . 73

B Cobertura de código 77 B.1 Passos necessários para a criação do relatório . . . 77

Lista de Figuras

1.1 Ecrã da aplicação Omni Notes com comportamento dinâmico . . . 3

1.2 Ecrã da aplicação Omni Notes que contém um widget com uma infinidade de eventos 3 3.1 Diagrama de componentes da abordagem implementada na iMPAcT tool [53] . . 24

3.2 Exemplo do padrão Side Drawer [22] . . . 28

3.3 Exemplo do padrão de Orientação. a) portrait e b) landscap [55] . . . 29

4.1 Aparecimento de novos elementos no ecrã após o clique no botão de pesquisa . . 36

4.2 Dois ecrãs com diferente tab selecionado . . . 42

4.3 Pedido de permissão para gravar áudio . . . 44

4.4 Exemplo de diferentes ecrãs de crash . . . 45

4.5 Passos para iniciar a reprodução do script . . . 46

Lista de Tabelas

5.1 Conjunto final de aplicações selecionadas . . . 54

5.2 Características do ACVTool e do JaCoCo . . . 54

5.3 Resultados de cobertura de eventos . . . 57

5.4 Resultados de cobertura de código . . . 58

5.5 Resultados de cobertura de eventos para a aplicação Omni Notes com um tempo máximo de exploração de 50 minutos . . . 59

5.6 Resultados de cobertura de código para a aplicação Omni Notes com um tempo máximo de exploração de 50 minutos . . . 59

Acrónimos

GUI Graphical User Interface UI User Interface

GPS Global Positioning System NFC Near Field Communication MBT Model-Based Testing DOC Double Orientation Change PBGT Pattern-Based GUI Testing

API Application Programming Interface APK Android Application Package URI Uniform Resource Identifier HTML HyperText Markup Language XML Extensible Markup Language SDK Software Development Kit

IDE Integrated Development Environment SATG Static Activity Transition Graph

Capítulo 1

Introdução

Este capítulo tem como objetivo fornecer uma visão geral sobre os temas abordados nesta dissertação, que incluem uma breve descrição do contexto no qual a dissertação está inserida, alguns desafios existentes, a sua motivação e objetivos e as principais contribuições do trabalho realizado. No final será apresentada e descrita a estrutura do presente documento.

1.1

Contexto

Atualmente, os smartphones estão cada vez mais importantes na vida do ser humano. Esta im-portância é, sobretudo, devido às suas capacidades que os fazem ser semelhantes a um computador pessoal.

Com a evolução dos smartphones e com a facilidade cada vez maior de desenvolver aplicações para dispositivos móveis, tem-se verificado uma rápida expansão do número destas aplicações. Neste mercado, há duas plataformas que se destacam conforme indicam os dados do segundo trimestre de 2018 [68]: Android, com uma quota de mercado de 88% e iOS, com uma quota de mercado de 12%. Assim, verifica-se que o Android é a plataforma de eleição para os utilizadores de smartphones entre as plataformas que se destacam.

No início de Novembro de 2018, o número de aplicações móveis disponíveis na Google Play Store situava-se acima dos 2.5 milhões [11] e no ano de 2017 existiram aproximadamente 178.1 mil milhões de downloads de aplicações móveis [66], o que demonstra a importância dos smartphonesno dia-a-dia da população mundial.

A rivalidade associada ao número crescente de aplicações móveis, bem como a existência de aplicações críticas, como aplicações de pagamentos, torna a tarefa de automatizar os testes nestas aplicações muito importante para garantir que estas funcionam da melhor maneira possível. É importante salientar que testar uma aplicação não vai garantir que esta não possui problemas, mas vai aumentar a confiança na sua qualidade.

2 Introdução

Teste baseado em modelos (MBT) é uma das técnicas para geração automática de casos de teste a partir de um modelo que descreve o sistema a testar. No entanto, esta técnica possui alguns problemas, como a própria necessidade de um modelo, cuja construção manual é um processo moroso e sujeito a erros [55]. Para contornar este problema, uma das possíveis soluções tem como base um processo de engenharia reversa dinâmico sustentado por uma exploração automática da aplicação, de modo a ser possível extrair parte do modelo para a técnica de MBT [52,55,63].

1.2

Problema

Atualmente, tem-se verificado um aumento da preocupação, por parte das empresas, no teste às aplicações móveis introduzidas no mercado. No entanto, existem alguns desafios na realização de testes a estas aplicações, sendo o tempo disponível um dos maiores no ano de 2017 [67].

O processo de exploração dinâmica, base de muitas ferramentas de testes automatizados, pos-sui também desafios que podem impedir que esta exploração atinja todos os estados existentes na aplicação em teste. Entre estes desafios, salientam-se os quatro seguintes:

• Possibilidade de existirem pontos de bloqueio como, por exemplo, um sistema de autenti-cação que impedem que a exploração atinja outras funcionalidades da apliautenti-cação;

• A evolução do mundo das aplicações móveis pode levar à introdução de novos gestos de interação não exercitados pelo algoritmo de exploração. Tendo em conta que certas partes da aplicação apenas podem ser acessíveis através de gestos específicos, torna-se importante que um algoritmo de exploração dinâmica seja atualizado de maneira a simular todas as formas de interação possíveis;

• Identificação de ecrãs diferentes pois não é possível saber dinamicamente quando a aplica-ção atinge um novo ecrã;

• Devido à natureza dinâmica das aplicações móveis, eventos que estavam disponíveis num ecrã podem deixar de o estar quando se retorna a esse mesmo ecrã. Além disto, ainda devido a esta natureza dinâmica, certas aplicações podem ter um número infinito de eventos num ecrã, fazendo com que a exploração fique presa nesse estado. A Figura1.1 e a Figura1.2 ilustram casos onde existe um elevado número de eventos para executar num mesmo ecrã. Na Figura1.1, sempre que um item é adicionado à lista (“New item”), um novo elemento da GUI surge imediatamente abaixo. Por esta razão, a lista de opções pode crescer de forma infinita (ou até um certo limite ser atingido). A Figura1.2representa um widget calendário com uma infinidade de eventos (datas). No entanto, interagir com todas as datas possíveis não contribui para o aumento do conhecimento da aplicação.

As questões de investigação definidas nas quais esta dissertação está centrada são as seguintes: QI 1 - É possível explorar automaticamente o comportamento das aplicações Android atra-vés de uma análise dinâmica?

1.3 Motivação e objetivos 3

Figura 1.1: Ecrã da aplicação Omni Notes com comportamento dinâmico

Figura 1.2: Ecrã da aplicação Omni Notes que contém um widget com uma infinidade de eventos

QI 2 - É possível obter melhores resultados que outros algoritmos já existentes no estado da arte?

QI 3 - É a cobertura de eventos diretamente proporcional à cobertura de código?

QI 4 - Qual o efeito de aumentar o tempo máximo da exploração na cobertura da aplicação? Estas questões guiaram as experiências realizadas de forma a que, com base nos resultados obtidos, elas fossem respondidas. Além disto, as respostas às questões ajudam a clarificar o real desempenho do algoritmo implementado em comparação com outros dois já existentes no estado da arte. Estas respostas podem ser encontradas na Secção5.5.

1.3

Motivação e objetivos

Com o aumento da preocupação em testar as aplicações móveis, começaram a surgir fra-meworksde teste não só oficiais como também não oficiais, que fornecem um conjunto de APIs para a criação de testes à interface do utilizador e que interagem com a aplicação e com outros serviços do sistema dinamicamente. Estas frameworks são a base de muitas das ferramentas de testes às aplicações móveis existentes.

4 Introdução

A fase de exploração dinâmica das interfaces de uma aplicação móvel é uma tarefa muito importante para muitas ferramentas de testes automatizados e prossupõe sempre uma condição de paragem que identifica quando a exploração da aplicação deve terminar. Esta exploração tem por base a simulação das interações de um utilizador na aplicação móvel, de forma a identificar e percorrer todos os seus estados.

A exploração da aplicação está diretamente relacionada com a sua cobertura, ou seja, quanto melhor for a exploração, maior será, teoricamente, o grau de cobertura dos testes na aplicação mó-vel. Uma boa exploração da aplicação é aquela que consegue atingir todos os estados da aplicação, exercitando todos os eventos disponíveis.

O foco deste trabalho de investigação está relacionado com a componente de exploração da iMPAcT tool (Mobile PAtterns Testing) [49,50,51,53,54,55]. Esta ferramenta foi desenvolvida num trabalho de investigação anterior e tem como objetivo verificar se as diretrizes fornecidas pela Google [23] para o desenvolvimento de aplicações Android estão implementadas corretamente. O processo de teste é feito de forma totalmente automática combinando engenharia reversa, para obter um modelo da aplicação, e identificação de UI Patterns. Caso algum padrão seja encontrado, a ferramenta aplica os Test Patterns correspondentes. Após o teste, a exploração da aplicação continua.

Assim, o principal objetivo desta dissertação consistiu em estender a iMPAcT tool, conce-bendo um novo algoritmo de exploração de aplicações móveis Android, de forma a aumentar a cobertura de código e de eventos nas suas execuções melhorando, consequentemente, os seus resultados. Esta dissertação encontra-se dividida em quatro fases:

1. Revisão do estado da arte – Esta fase consistiu na recolha de informação sobre o estado da arte dos tópicos envolvidos na dissertação. O resultado desta revisão é apresentado no Capítulo2;

2. Análise da iMPAcT tool – Após a revisão do estado da arte, foi necessário analisar a iM-PAcT tool, ferramenta que é a base desta dissertação. Esta análise é apresentada no Capítulo 3e inclui a abordagem de teste da ferramenta, o seu catálogo de padrões, os artefactos pro-duzidos, entre outros;

3. Implementação – Esta fase consistiu na implementação do novo algoritmo de exploração. O Capítulo4apresenta os detalhes desta implementação;

4. Validação – Finalmente, a última fase passou pela realização de duas experiências para validar o algoritmo implementado. Estas experiências e os seus resultados encontram-se apresentados no Capítulo5.

1.4

Contribuições

1.5 Estrutura do documento 5

1. Um algoritmo de exploração dinâmica de aplicações móveis que ajuda a resolver os proble-mas identificados na Secção1.2;

2. Um mecanismo que permite gravar uma exploração e reproduzi-la de forma a verificar se os problemas identificados durante essa exploração ainda existem;

3. Um artigo com a descrição do algoritmo de exploração desenvolvido e dos resultados das ex-periências realizadas. Este artigo foi submetido e aceite na conferência QUATIC a realizar-se em realizar-setembro de 2019: J.M.R. Ferreira, A.C.R. Paiva. “Android Testing Crawler”. Em 12th International Conference on the Quality of Information and Communications Techno-logy, Ciudad Real, Espanha, Setembro 11–13, 2019.

1.5

Estrutura do documento

Este documento está estruturado em seis capítulos. O presente e primeiro capítulo introduz o tema trabalhado na dissertação, definindo o contexto, os problemas, a motivação e os objetivos da mesma e, finalmente, as contribuições oferecidas por este trabalho. O Capítulo 2 apresenta os resultados da pesquisa realizada relativamente ao estado da arte, que incluem ferramentas e metodologias de testes, engenharia reversa, cobertura e exploração em aplicações móveis Android. O Capítulo 3 descreve a ferramenta na qual esta dissertação se baseia. O Capítulo 4 descreve os detalhes de implementação do novo algoritmo de exploração e do script de reprodução. O Capítulo 5 apresenta os resultados das experiências realizadas para validação do algoritmo de exploração desenvolvido. Finalmente, no Capítulo6são apresentadas as conclusões e o trabalho futuro.

Capítulo 2

Estado da arte

O presente capítulo é dividido em seis principais secções. Na Secção2.1é feita uma revisão do estado da arte relativo ao processo de teste de aplicações móveis. Na Secção2.2é explicada a técnica de teste baseado em modelos. Na Secção2.3 é descrito o estado atual da engenharia reversa com especial ênfase em dispositivos móveis. A Secção2.4sumaria o estado atual da arte relativo a abordagens e ferramentas associadas à cobertura de aplicações móveis. Na Secção2.5 é sintetizado o estado atual da exploração dinâmica de aplicações móveis. Finalmente, a última secção serve como conclusão à revisão da literatura realizada.

2.1

Testes a aplicações móveis

Uma aplicação móvel é uma aplicação projetada para ser executada num dispositivo móvel, como um smartphone ou tablet. Por norma, estas aplicações são pequenas e construídas de forma a poderem usufruir de recursos especificas do dispositivo.

Com o rápido crescimento do número de aplicações móveis, torna-se essencial garantir o seu correto funcionamento. Por esta razão, é importante a criação de técnicas que melhorem a auto-matização do processo de teste. Atualmente, no que diz respeito a esta autoauto-matização, o foco das abordagens existentes pode ser na geração de testes ou na sua execução. No entanto, a comunidade tem vindo a dar especial atenção à automatização de geração de casos de teste devido à existência de frameworks e ferramentas que facilitam o processo da sua execução [49]. Estas ferramentas serão descritas com mais pormenor na Subsecção2.1.3.

2.1.1 Automatização de testes a aplicações móveis

No seu estudo em 2012, Muccini et al. [56] identificaram diversas peculiaridades que fazem do teste a aplicações móveis diferente do teste a aplicações tradicionais. Entre estas peculiaridades destacam-se os recursos limitados, a baixa autonomia, os novos conceitos de desenvolvimento, a diversidade de dispositivos móveis e das suas características e o facto de serem cientes do contexto,

8 Estado da arte

isto é, as aplicações móveis dependem de dados obtidos pelos provedores de contexto (como o GPS, Wi-Fi, 3G, Sensor de luz, etc).

Além disso, Muccini et al. identificaram diferentes tipos de testes que devem ser realizados a aplicações móveis:

• Performance and reliability testing – Validar o comportamento da aplicação relativamente aos recursos disponíveis, qualidade da conectividade e a outros tipos de informação con-textual. Berardinelli et al. [15] apresentaram uma framework para modelar e analisar o desempenho de aplicações móveis cientes do contexto. Em 2018, Delia et al. [21] apre-sentaram um estudo relativamente ao desempenho das abordagens usadas para desenvolver aplicações móveis para Android e iOS. Neste estudo, os autores constatam ainda que o desempenho de uma aplicação móvel afeta a preferência do utilizador para o seu uso. • Memory and Energy testing – Verificar a existência de memory leaks. Este tipo de teste é

importante devido aos recursos limitados de memória e à pouca autonomia que, por norma, caracterizam os dispositivos móveis. Palit et al. [60] apresentou uma metodologia para se-lecionar casos de teste com o intuito de realizar avaliações do custo de energia de aplicações móveis. Em 2018, Banerjee et al. [14] consideraram os problemas de eficiência de ener-gia em aplicações móveis como bugs de enerener-gia. Neste estudo, os autores desenvolveram o EnergyPatch, uma framework que faz uma análise híbrida para detetar, validar e reparar bugsde energia em aplicações Android.

• Security testing – Controlar o acesso a informação sensível e privada (palavras-passe, loca-lização, etc). A garantia de segurança e privacidade é crucial nas aplicações móveis não só devido ao aumento do uso de aplicações críticas mas também devido à natureza móvel do dispositivo que o pode fazer aceder a diferentes redes com diferentes níveis de segurança. Em 2016, Keng et al. [36] apresentaram o MAMBA, um sistema de teste para análise de privacidade em aplicações Android. O trabalho realizado por Knorr et al. [38] é outro exem-plo deste tipo de teste. Neste trabalho, foi proposta uma abordagem para testar aplicações Android na área da saúde que considerava possíveis cenários de ataque e vulnerabilidades especificas do domínio.

• GUI testing – Garantir o correto comportamento da GUI de uma aplicação móvel. Este tipo de teste é importante porque a GUI é o único canal de comunicação entre o utilizador e a aplicação. Existem algumas abordagens, propostas por diversos autores, que têm como objetivo encontrar falhas na GUI. A iMPAcT tool [49,50,51,53,54,55], alvo desta disser-tação, é um exemplo de uma ferramenta que testa a interface do utilizador e que se encontra descrita no capítulo3. Nu et al. [32] apresentaram uma abordagem para detetar bugs na GUI de uma aplicação Android através da geração automática de casos de teste, execução de eventos aleatórios e produção e análise de ficheiros com informações detalhadas sobre a aplicação. Costa et al. [19] apresentaram uma abordagem de teste à GUI onde eram gerados casos de teste a partir de um modelo baseado em padrões da aplicação.

2.1 Testes a aplicações móveis 9

• Product line testing – Garantir o correto funcionamento de uma aplicação em diferentes dis-positivos. Estes testes são importantes devido às diferentes características dos dispositivos móveis presentes no mercado, sobretudo quando nos referimos aos dispositivos Android. No entanto, devido ao elevado número de dispositivos com diferentes características, torna-se praticamente impossível testar uma aplicação móvel em todos estes dispositivos. Por esta razão, Zhu et al. [17] propuseram uma abordagem para seleção de dispositivos móveis de teste usando um algoritmo genético multiobjectivo. Esta seleção é feita tendo em conta vários requisitos como: custo do teste, cobertura das plataformas e cobertura das caracterís-ticas dos dispositivos.

Em 2014, Gal et al. [30] identificaram as principais infraestruturas de teste de aplicações móveis:

• Emulation-based testing – Envolve o uso de um emulador, que cria uma máquina virtual do dispositivo móvel no computador. Apesar de ser uma técnica com baixo custo, ela possui várias limitações, tais como a sua ineficiência a avaliar a qualidade do serviço da aplicação. • Device-based testing – Consiste na execução dos testes da aplicação num dispositivo real. Envolve um custo maior que o baseado em emulação devido à necessidade de aquisição dos dispositivos.

• Cloud testing – Baseado em dispositivos ou emuladores que são acessíveis através da cloud nos quais as aplicações podem ser instaladas e os testes executados.

• Crowd-based testing – Baseado num conjunto de pessoas que usam a aplicação. Devido à tendência emergente deste tipo de infraestrutura, Zhang et al. [78] propuseram uma aborda-gem para melhorar o poder do público no teste de aplicações Android.

2.1.2 Testes de caixa branca e testes de caixa preta

Existem duas técnicas de teste de software principais para encontrar possíveis erros em apli-cações:

• Testes de caixa branca – Nesta técnica o tester tem acesso ao código fonte e conhece a estrutura interna da aplicação. Ela tem como principal objetivo revelar erros de implemen-tação da aplicação em teste, analisando o seu funcionamento interno [28].

• Testes de caixa preta – Técnica na qual a funcionalidade da aplicação é testada sem ter conhecimento da sua estrutura interna. Nesta técnica não existe acesso ao código fonte da aplicação e apenas são verificadas as saídas geradas com base nas entradas que foram fornecidas.

Existe ainda outra técnica que resulta da combinação das duas anteriores: testes de caixa cinza. Esta técnica é usada para testar uma aplicação com conhecimento do seu mecanismo interno e também com conhecimento dos requisitos fundamentais do sistema [28].

10 Estado da arte

2.1.3 Ferramentas de suporte

Nesta subsecção serão descritas algumas ferramentas de suporte a abordagens de teste de apli-cações móveis Android.

2.1.3.1 UI Automator

O UI Automator [8] é uma framework de testes oficial da Google, cuja primeira versão surgiu em novembro de 2012. Esta framework fornece um conjunto de APIs para a criação de testes à interface do utilizador que interagem não só com as aplicações do utilizador, mas também com as aplicações do próprio sistema. A framework é adequada para a criação de testes de caixa preta. As suas principais funcionalidades incluem:

• Um visualizador capaz de obter e analisar os componentes da interface do utilizador, que estão a ser mostrados no dispositivo nesse momento;

• Uma API para aceder e realizar operações no dispositivo Android no qual a aplicação está a correr. Esta API permite também aceder às propriedades do dispositivo;

• Várias APIs que permitem escrever testes robustos à interface do utilizador de uma aplica-ção. Estas APIs suportam a criação de testes cross-app.

As principais desvantagens desta framework são:

• Os dispositivos de destino devem ter a versão 4.3 ou acima do Android; • Apenas suporta aplicações nativas.

2.1.3.2 Espresso

O Espresso [7] é uma framework oficial disponibilizada pela Google, tendo a sua versão 2.0 sido lançada em dezembro de 2014. Ela fornece um conjunto de APIs para a criação de testes à interface do utilizador que testam casos de uso da aplicação. O estilo de teste do Espresso é considerado de caixa branca e, por esta razão, ele é focado numa única aplicação. As principais funcionalidades desta framework são:

• APIs capazes de aceder aos elementos presentes na interface do utilizador de forma a inte-ragir com eles;

• Um conjunto de APIs que facilitam a automatização das interações na interface do utiliza-dor;

2.1 Testes a aplicações móveis 11

A maior vantagem do Expresso é a sua capacidade de sincronização automática das ações de teste com a interface de utilizador da aplicação, isto é, não é necessário esperar tempo após as interações para garantir que a interface respondeu. Outra das vantagens é a grande percentagem de dispositivos que suporta, visto que apenas exige a versão 2.2 ou superior do Android. A maior desvantagem desta framework é que ela apenas suporta aplicações nativas.

2.1.3.3 Robotium

O Robotium [62] é uma das frameworks de teste não oficiais mais populares no mundo An-droid, tendo a sua primeira versão sido lançada em janeiro de 2010. Esta framework possui uma API simples que facilita o processo de criação de testes automáticos à interface do utilizador. Algumas das suas principais vantagens são:

• Suporte para o teste de aplicações nativas e híbridas;

• Grande percentagem de dispositivos suportado, visto que apenas necessita da versão 2.2 ou superior do Android;

• Possui um estilo de teste caixa preta;

• Capacidade de gerir automaticamente várias atividades na aplicação;

• Pode ser integrado facilmente com o Maven, Gradle ou Ant para executar testes como parte da integração contínua;

• Casos de teste são robustos devido ao binding em tempo real nas componentes da interface; • Capacidade para aceder e modificar os serviços e os sensores do dispositivo.

No entanto, como em todas as frameworks existentes, ela possui também algumas desvanta-gens que incluem [53]:

• O nome da atividade principal da aplicação em teste deve estar hard coded;

• Apenas é possível aceder aos serviços e sensores para os quais a aplicação em teste tem permissão;

• Não é possível ler o conteúdo de um ecrã. 2.1.3.4 Appium

O Appium [12] é uma framework de automatização de testes open source que surgiu em abril de 2013. As suas principais vantagens são:

12 Estado da arte

• É cross-platform, ou seja, permite escrever testes para várias plataformas, através da mesma API;

• Não necessita de acesso ao código da aplicação em teste; • Suporta diferentes linguagens e frameworks;

• Os testes podem ser executados num emulador ou num dispositivo real; • Permite aceder e modificar o estado dos serviços e sensores do dispositivo;

• Nome do package da aplicação e o nome da sua atividade principal podem ser fornecidos como input.

Contudo, o Appium possui também algumas desvantagens [53]:

• Não está ainda num estado estável, produzindo, por vezes, alguns erros inesperados; • Não consegue ler os conteúdos do ecrã;

• Não é possível localizar um elemento pelo seu identificador. 2.1.3.5 Selendroid

O Selendroid [26] é também uma framework open source de automatização de testes à UI de aplicações Android. Algumas das vantagens desta framework são:

• Suporte para o teste de aplicações nativas, híbridas e web; • Pode ser usada em emuladores ou em dispositivos reais; • Suporta praticamente todas as versões do Android; • Não necessita de acesso ao código da aplicação em teste;

• Dispositivos externos podem ser conectados e desconectados do computador durante a exe-cução do teste, sem este reiniciar ou parar;

• Suporta o reconhecimento dos elementos usando as suas propriedades;

• Tem incorporada uma ferramenta de inspeção que ajuda a identificar elementos da interface da aplicação em teste.

As principais desvantagens do Selendroid são [53]:

• Não é possível aceder nem modificar o estado dos sensores e serviços do dispositivo; • A ferramenta de inspeção não pode ser usada programaticamente porque esta não oferece

2.2 Teste baseado em modelos 13

2.1.3.6 Calabash

Desenvolvido pela equipa do Xamarin, o Calabash [73] surgiu em 2012 e é uma framework de teste open source que funciona tanto em Android como em iOS. Algumas das principais vantagens desta framework são:

• É possível ter acesso e modificar o estado dos sensores e serviços do dispositivo; • Possui uma sintaxe de fácil compreensão;

• É possível correr os testes em emuladores ou em dispositivos reais; • Apresenta relatórios de desempenho do hardware do dispositivo; • Tem suporte para o teste de aplicações nativas e híbridas.

Algumas das desvantagens do Calabash são [53]: • Não é possível ler o conteúdo de um ecrã;

• Apenas é possível usar a linguagem de programação Ruby; • O estilo de teste é caixa branca;

• A sua configuração é mais complicada que a do Appium.

2.2

Teste baseado em modelos

A técnica de teste baseado em modelos permite a geração automática de casos de teste [55,37, 43,47,58,71,74]. Para isto, é necessário fornecer um modelo do comportamento da aplicação e, a partir deste, são criados os casos de teste para execução. No entanto, esta técnica possui dois problemas principais [55]:

• A necessidade de um modelo da aplicação como input, cujo processo de construção é mo-roso e sujeito a erros;

• A explosão combinatória de casos de teste.

O primeiro problema pode ser resolvido por um processo de engenharia reversa da aplicação em teste ou através do aumento do nível de abstração dos modelos. O segundo problema pode ser resolvido escolhendo um conjunto dos testes para execução ou focando-se numa área específica da aplicação [55].

O Pattern-Based GUI Testing (PBGT) [46,48] é uma abordagem de teste baseado em modelos, cujo principal objetivo é automatizar e sistematizar o processo de teste à interface do utilizador. Nesta abordagem são resolvidos os principais problemas deste tipo de técnica. Em primeiro lu-gar, o esforço de construção do modelo é reduzido comparado com outras técnicas de modelação da GUI. Em segundo lugar, esta abordagem foca-se numa área especifica da aplicação, testando apenas comportamento recorrente, isto é, UI Patterns.

14 Estado da arte

2.3

Engenharia reversa

A maior parte das abordagens de engenharia reversa existentes foca-se em aplicações web, como é o caso do trabalho realizado por Maezawa et al. [42] que apresenta uma abordagem estática para extrair todas as transições de estados possíveis descritas no código fonte da aplicação web. Existem também abordagens a aplicações desktop, tais como o GUISurfer [64] que permite extrair modelos de comportamentos de aplicações com GUI através de uma análise estática. No entanto, com o aumento da importância e uso dos smartphones, tem-se verificado um crescimento do número de abordagens de engenharia reversa a aplicações móveis.

No contexto desta dissertação, a pesquisa em engenharia reversa presente nesta secção está associada a aplicações móveis Android.

As abordagens de engenharia reversa podem ser divididas em três tipos:

• Estática – Recolha de informação através da análise direta do código fonte da aplicação; • Dinâmica – Obtenção de informação através da análise da aplicação em execução;

• Híbrida – Extração de informação através da análise da aplicação em execução e do seu código fonte.

Devido à natureza dinâmica e baseada em eventos das aplicações móveis, quando o objetivo de uma abordagem é testar o comportamento da aplicação, a análise estática não é a ideal [50,53]. As abordagens de engenharia reversa em aplicações móveis podem servir de suporte tanto para a construção de modelos, de forma a melhor compreender a aplicação, como para implementações de abordagens de teste.

Em 2011, Amalfitano et al. divulgaram o A2T2 [1], uma ferramenta de crawling capaz de testar uma aplicação para verificar a existência de crashes. Esta ferramenta é também capaz de extrair o modelo da aplicação que é constituído pelas suas interfaces e a relação entre elas. Em 2012, eles desenvolveram o AndroidRipper [2]. Esta ferramenta faz uma análise dinâmica da interface da aplicação em teste de forma a obter sequências de eventos que possam ser executados através dos widgets da GUI e é capaz de extrair a árvore de interfaces e de testar a aplicação para verificar a presença de crashes.

Yang et al. [75] apresentaram uma abordagem para extrair automaticamente um modelo de uma aplicação móvel Android. Nesta abordagem é realizada uma análise estática para obter os eventos suportados pela GUI da aplicação em teste. Após esta fase, é feita uma exploração dinâ-mica da aplicação para obter o seu modelo.

De forma a analisar as vulnerabilidades associadas à segurança de uma aplicação, Dar e Parvez [20] propuserem a implementação de um abordagem que começa por descompilar uma aplicação Android e remover as permissões indesejadas. Após esta fase, é feita uma análise do código fonte da aplicação para implementar as aprovações das permissões em tempo de execução. Finalmente, o código é recompilado e, em tempo de execução, é perguntado ao utilizador se pretende fornecer ou não as permissões necessárias.

2.4 Cobertura 15

Em 2016, Ting Su [69] propôs o FSMdroid, uma ferramenta que combina engenharia reversa com a técnica de teste baseado em modelos para testar uma aplicação Android. O processo de engenharia reversa inclui uma análise dinâmica para obter a máquina de estados da aplicação e uma análise estática para identificar os eventos da interface que podem não ser encontrados durante a análise dinâmica.

2.4

Cobertura

Para avaliar se os testes realizados a uma aplicação abrangem toda esta aplicação, é feita, normalmente, uma análise de cobertura dos testes. Em particular, no que respeita a aplicações móveis, existem duas análises de cobertura que podem ser realizadas:

• Cobertura de código – É uma medida que indica a quantidade do código da aplicação que foi executado durante os testes. Esta análise inclui diversos tipos de cobertura como: classes, métodos, linhas, entre outros.

• Cobertura de eventos – Devido à natureza baseada em eventos das aplicações móveis, torna-se importante analisar também a quantidade de eventos que foram exercitados durante os testes. Esta análise é particularmente útil quando se pretendem validar técnicas de análise dinâmica de aplicações móveis.

Relativamente ao tipo de teste a executar, as técnicas de cobertura de código podem ser dividi-das em dois tipos: 1) cobertura para testes de caixa branca; 2) cobertura para testes de caixa preta. A maior parte das ferramentas de exploração a aplicações móveis enquadra-se neste segundo tipo. De seguida, são apresentados alguns trabalhos recentes no que diz respeito a cobertura para testes de caixa preta.

Em 2015, Yeh et al. apresentaram o CovDroid [76], uma ferramenta para medir a cobertura de testes do estilo caixa preta em aplicações móveis Android. Esta ferramenta possui três módulos: instrumentação, monitorização da execução e gestor de relatórios de cobertura. No módulo de instrumentação, a aplicação em teste é descompilada para o formato Jasmin [35] usando o smali [65], instrumentada ao nível da classe, recompilada e automaticamente instalada no dispositivo Android. O módulo de monitorização analisa a execução da aplicação através do Android Debug Bridge [6] produzindo o registo desta execução. Finalmente, o módulo gestor de relatórios de cobertura analisa o registo produzido e calcula a cobertura para os casos de teste executados.

Zhauniarovich et al. propuseram o BBOXTESTER [79], uma framework para gerar relatórios de cobertura de código no teste de aplicações Android. Tal como o CovDroid, esta framework é constituída por três componentes principais: Instrumenter, Executor e Reporter. O Instrumenter faz uso do apktool [10] para descompilar o APK e extrair os ficheiros .dex e o manifesto da aplicação. De seguida, estes ficheiros .dex são processados com o dex2jar [25] para transformar o bytecodeDalvik em bytecode Java que é posteriormente instrumentado com a ferramenta Emma [29]. Após esta instrumentação, os ficheiros Java são recompilados em ficheiros .dex, e estes no APK final utilizando novamente o apktool. O Executor instala a aplicação no dispositivo, inicia

16 Estado da arte

e termina a sua execução, extrai os resultados e desinstala a aplicação. Durante o início e o fim da execução, o utilizador pode correr os seus próprios casos de testes ou explorar a aplicação manualmente. Finalmente, o Reporter cria relatórios de cobertura com base nos dados gerados durante a instrumentação e execução da aplicação. Nestes relatórios está presente informação de cobertura ao nível da classe, método e bloco básico.

Huang et al. [33] reconheceram que, apesar da sua importância, a capacidade de cobertura da maior parte de ferramentas de análise dinâmica é desconhecida. Desta forma, apresentaram uma abordagem semelhante à presente no CovDroid e no BBOXTESTER que consiste em extrair os ficheiros do APK e descompilá-los usando o smali. De seguida, através de um compilador implementado pelos autores, é feito parse ao código dos ficheiros smali e é feita a sua instrumen-tação. Este código de instrumentação é inserido de forma a dar informação de cobertura ao nível da classe, método, bloco e linha. Finalmente, é feita a recompilação em ficheiros .dex (usando o smali) e estes no ficheiro APK (usando o apktool). Nesta fase, a aplicação está pronta para ser executada de forma a serem produzidos os resultados de cobertura.

Em 2017, Liu et al. apresentaram o InsDal [40], uma ferramenta para inserir instruções no bytecodeDalvik de acordo com requisitos específicos do utilizador, como as instruções que devem ser instrumentadas. A ferramenta possui três módulos: Disassembling and Repackaging, Analysis e Instrumentation. O módulo Disassembling and Repackaging é responsável por extrair o bytecode Dalvik do APK e por recompilar os ficheiros modificados num novo APK (usando o apktool). O módulo Analysis é responsável por determinar que instruções serão inseridas de acordo com os requisitos do utilizador. Por último, o módulo Instrumentation consiste em três fases: 1) procurar registos seguros para o código instrumentado; 2) instrumentar as instruções de acordo com os resultados do módulo Analysis; 3) otimizar o código instrumentado de forma a reduzir os recursos necessários. De acordo com os autores, esta ferramenta pode ajudar a medir a cobertura de código e a obter o trace de execução da aplicação.

Mais recentemente, Pilgun et al. apresentaram o ACVTool [61], uma ferramenta de instrumen-tação de aplicações Android para medir a cobertura do código smali ao nível da classe, método e instrução. Esta ferramenta possui três fases relativamente ao seu fluxo de trabalho: 1) offline, 2) online e 3) geração do relatório. A fase offline é responsável por todo o pré-processamento da aplicação que inclui a descompilação, instrumentação, recompilação e assinatura. A fase online é responsável pela instalação da aplicação no dispositivo e pela recolha dos dados de cobertura du-rante os testes. A última fase consiste na produção do relatório de cobertura do código em formato HTML e XML. Este relatório é produzido com base nos dados recolhidos na fase anterior e nos que foram criados ao instrumentar a aplicação. Na avaliação realizada pelos autores, a ferramenta foi capaz de instrumentar com sucesso 96.9% das aplicações utilizadas.

No que diz respeito à medição de cobertura a testes de caixa branca, existem já algumas ferramentas disponíveis para uso. O restante desta secção apresenta duas das ferramentas mais populares relativamente a este tipo de cobertura.

O Emma [29] é uma ferramenta open source de cobertura baseada em Java. Esta ferramenta tem algumas vantagens como: 1) produção de um relatório detalhado com informação ao nível

2.5 Exploração dinâmica 17

da classe, método, bloco e linha; 2) está incorporada no Android SDK; 3) bom desempenho. No entanto, esta ferramenta possui também alguns problemas como: 1) ausência de suporte para instrumentação on-the-fly, ou seja, não é possível medir a cobertura de binários pré-compilados; 2) não possui cobertura ao nível do branch; 3) apenas suporta bytecode Java [76]; 4) é necessário fazer pequenas alterações ao código fonte para que a ferramenta funcione; 5) relatório dos testes é criado no dispositivo.

O JaCoCo [27] é também uma ferramenta popular de análise de cobertura open source. As suas principais vantagens são: 1) fácil integração com vários IDEs; 2) produção de um relatório detalhado com informação ao nível da classe, método, bloco, linha e branch; 3) bom desempenho; 4) suporta instrumentação on-the-fly e offline. Apesar disto, existem também alguns problemas com a ferramenta como: 1) é necessário fazer pequenas alterações ao código fonte para que a ferramenta funcione; 2) relatório dos testes é criado no dispositivo.

2.5

Exploração dinâmica

As técnicas de exploração dinâmica da interface são muito usadas no contexto de aplicações móveis devido à sua natureza baseada em eventos. Estas técnicas podem fornecer suporte a pro-cessos de engenharia reversa ou a propro-cessos de teste a estas mesmas aplicações.

As abordagens de exploração dinâmica de uma aplicação móvel podem seguir diferentes es-tratégias:

• Aleatória – São gerados eventos aleatórios nas interfaces da aplicação;

• Heurística – A decisão do evento a ser executado é feita com base em heurísticas que guiam todo o processo de exploração;

• Active Learning – O modelo é construído à medida que são feitos testes à aplicação. Com base nesse modelo, é decidido que evento deve ser executado.

O restante desta secção descreve algumas ferramentas e trabalhos recentes na área de explora-ção dinâmica em aplicações móveis.

O Monkey [9] é uma ferramenta da Google incorporada no Android SDK. Esta ferramenta é capaz de gerar sequências de eventos pseudoaleatórios diretamente na interface de uma aplicação Android de forma automática, sendo que o seu principal objetivo é detetar possíveis crashes na aplicação em teste. Esta ferramenta permite ainda que uma execução seja reproduzida mais tarde, bastando para isso que o valor da opção seed, usado para geração de números pseudoaleatórios, seja o mesmo nas duas execuções.

Em 2014, Wang et al. [72] apresentaram uma abordagem que considerava a estrutura de uma aplicação Android como uma árvore de interfaces, onde cada nó representa uma GUI e uma aresta representa uma interação entre duas GUIs. Esta abordagem possui um algoritmo de exploração em profundidade onde os eventos que são executados dependem da análise dinâmica feita à interface atual da aplicação. Neste algoritmo são guardadas duas listas: 1) lista hierárquica que guarda os

18 Estado da arte

componentes, layout e descrições das interfaces e a 2) lista de eventos que guarda os eventos exe-cutados em cada elemento. Nesta abordagem existe ainda uma técnica de rollback que é aplicada para obter a próxima interface alvo (última interface ainda não totalmente explorada) quando a exploração da lista hierárquica termina. Esta técnica de rollback consiste em: 1) parar a aplicação; 2) voltar a iniciar a aplicação; 3) executar os eventos na lista de eventos até ser atingida a próxima interface alvo. Esta abordagem encontra-se implementada numa ferramenta, DroidCrawle.

Machiry et al. [41] propuseram o Dynodroid, um sistema para geração de sequências de inputsrelevantes numa aplicação Android. Neste trabalho, os autores reconheceram a necessidade de introduzir inteligência humana para exercitar certas funcionalidades da aplicação que de forma automática não seria possível. Desta forma, o sistema permite que o utilizador pause a geração de eventos do sistema, introduza a sua sequência de eventos diretamente na interface da aplicação móvel e retome novamente a geração de eventos do sistema. Este sistema é composto por três componentes: 1) executor, responsável pela execução dos eventos selecionados pelo selector e pela troca entre a geração automática e a geração manual de eventos; 2) observer, encarregue de calcular o conjunto de eventos relevantes sempre que um evento é executado; 3) selector, responsável por selecionar o evento a executar a partir do conjunto de eventos calculado pelo observer.

Moran et al. [44, 45] apresentaram o CrashScope, uma ferramenta que explora dinamica-mente uma aplicação Android e que extrai os componentes da interface à medida que estas são exploradas. Durante a exploração, a ferramenta identifica os componentes que são clickable e long-clickablee adiciona-os a uma stack dinâmica de componentes para serem executados. Ainda durante esta fase, são também identificados os componentes de input de texto disponíveis. Para estes componentes é detetado o tipo de texto esperado e, após esta deteção, é gerado este mesmo texto de acordo com duas heurísticas: 1) esperada, que gera uma string de acordo com os pa-râmetros do teclado, sem pontuação ou caracteres especiais e 2) não esperada, que gera strings aleatórias com todos os caracteres permitidos. O seu objetivo é tentar detetar crashes devido ao incorreto tratamento do texto de input no código da aplicação. Ao longo da execução, o CrashS-cope guarda informação sobre a aplicação como os inputs, screenshots, exceções e crashes de forma a serem produzidos relatórios e scripts para reprodução da execução.

Azim et al. [13] apresentaram o A3E, uma ferramenta que implementa uma estratégia de exploração a aplicações Android baseada em modelos. Esta ferramenta possui dois modos de exploração: 1) Depth-first Exploration, que tem como objetivo explorar a aplicação de modo se-melhante a um utilizador, isto é, injetando uma sequência de eventos na interface da aplicação Android; 2) Targeted Exploration, cujo objetivo é obter uma rápida exploração das atividades fa-zendo uso de um SATG (Static Activity Transition Graph). Os autores reconheceram a existência de atividades especiais, isto é, atividades que não podem ser invocadas com a interação do utiliza-dor na aplicação e, por esta razão, implementaram o modo Targeted Exploration, capaz de listar todas as atividades que podem ser chamadas sem a intervenção do utilizador e gerar chamadas que invoquem estas mesmas atividades. Como resultado da exploração são criados relatórios com o traceda execução e com informação de cobertura.

2.5 Exploração dinâmica 19

Em 2013, Choi et al. propuseram o SwiftHand [18], uma técnica automática que utiliza active learningpara construir o modelo da aplicação durante os testes. O algoritmo de exploração au-tomática implementado nesta técnica faz uso do modelo da aplicação construído até ao momento para selecionar o próximo evento a executar. Caso seja detetado um componente na interface com o tipo EditText, é gerada uma string pré-definida ou aleatória de forma a melhorar o processo de exploração. O SwiftHand tenta explorar todos os estados da aplicação que podem ser atingidos pelo seu estado inicial de forma a reduzir o número de reinícios da aplicação e, por conseguinte, reduzir o overhead introduzido por este reinício. Os autores reconhecem ainda que a única forma fiável de reiniciar uma aplicação é através da sua desinstalação e posterior reinstalação, principal-mente quando a aplicação em questão possui informação persistente.

AndroidRipper [2] é uma ferramenta desenvolvida por Amalfitano et al. que implementa es-tratégias de exploração aleatória e sistemática à interface de uma aplicação móvel Android. Esta ferramenta tem como objetivo detetar falhas na aplicação que podem depender de diversos fatores. Por esta razão, o utilizador da ferramenta pode configurar previamente a estratégia de exploração atribuindo valores aos seus parâmetros, como o tempo entre a execução de dois eventos consecuti-vos, valores para os componentes de input nas interfaces, critério de exploração da interface, entre outros. O funcionamento do AndroidRipper baseia-se em três fases. A primeira fase consiste em atravessar a aplicação injetando eventos e extrair a máquina de estados que representa a aplicação. A segunda fase consiste na geração das diferentes sequências de eventos. Finalmente, na terceira fase os casos de teste são executados de forma a detetar falhas na aplicação em teste. Alguns anos mais tarde, esta abordagem foi melhorada, surgindo o MobiGUITAR [3], uma ferramenta de testes baseados em modelos.

Hao et al. [31] apresentaram o PUMA, uma framework programável que pode ser usada para analisar dinamicamente certas propriedades de uma aplicação Android, tal como a segurança ou o desempenho. Esta framework incorpora na sua análise dinâmica a estratégia básica de exploração do Monkey que pode ser configurável de forma a guiar o processo de exploração da aplicação. O PUMA recebe dois inputs do utilizador: 1) o binário da aplicação e 2) o código específico do utilizador, escrito em linguagem PUMAScript. Este código fornecido como input contém diretivas especificas da aplicação e diretivas especificas do Monkey. As diretivas especificas da aplicação indicam que partes do código são importantes para análise e as ações a executar quando esse código é atingido. As diretivas especificas do Monkey fornecem informação que guia o processo de execução da aplicação pelo Monkey.

Stoat [70] é uma abordagem para executar testes estocásticos baseados em modelos a apli-cações Android. O processo de operação da abordagem apresenta duas fases. A primeira fase consiste na construção da máquina de estados finita estocástica, que descreve o comportamento da aplicação, através de uma análise dinâmica e estática da aplicação. Na análise dinâmica, os eventos são inferidos através da leitura da hierarquia das interfaces existentes na aplicação e é criada uma prioridade para estes de forma a maximizar a cobertura de código. Na análise estática, é analisado o código da aplicação para identificar eventos que não tenham sido encontrados pela análise dinâmica. A segunda fase consiste, a partir do modelo construído na fase anterior, na

gera-20 Estado da arte

ção de testes de forma a criar diversas sequências de eventos a executar. Ao longo dos testes, são também executados eventos do sistema de forma aleatória para melhorar a eficácia do processo de teste. Esta abordagem é uma evolução ao FSMdroid [69].

Droidmate [34] é uma ferramenta automática para geração de testes através de uma explora-ção dinâmica da aplicaexplora-ção Android em teste. Esta ferramenta efetua uma ligeira modificaexplora-ção ao nível do bytecode Dalvik das aplicações para permitir a monitorização dos métodos das APIs do Android SDK. Após a modificação, a aplicação é instalada no dispositivo e a sua atividade princi-pal iniciada. Nesta fase, a ferramenta começa o processo de exploração da aplicação que consiste em: 1) ler a interface do dispositivo em tempo de execução e verificar as chamadas aos métodos das APIs do Android SDK; 2) decidir que evento executar com base na estratégia de exploração configurada e nos dados recolhidos. Em 2018, a abordagem presente no Droidmate foi melho-rada surgindo o Droidmate-2 [16]. Esta nova ferramenta estende o mecanismo de exploração do Droidmate, com a inclusão de um conjunto de estratégias de exploração e de seletores que ajudam a decidir o próximo evento a executar, com base no estado atual da aplicação.

Muslu et al. [39] propuseram uma abordagem de exploração de aplicações Android baseada em Q-Learning. Esta abordagem é dividida em três fases diferentes. A primeira fase consiste na execução de um conjunto de aplicações Android de treino através de uma estratégia de exploração aleatória de forma a serem obtidos os seus modelos. Na segunda fase, os modelos obtidos são usados para a construção da Q-Matrix relativamente a um objetivo específico. Este objetivo pode ser detetar um crash ou aumentar a cobertura de atividades da aplicação móvel em teste. Final-mente, na terceira fase, é possível testar uma aplicação Android através da execução das ações fornecidas pela Q-Matrix. No final do processo de teste, é criado um modelo da aplicação para facilitar a técnica de teste baseado em modelos. Esta abordagem encontra-se implementada na ferramenta AndroFrame, juntamente com uma estratégia de exploração aleatória e uma estratégia de exploração em profundidade.

Mais recentemente (2019), Amalfitano et al. [4] apresentaram o juGULAR, uma abordagem de exploração híbrida que combina exploração automática da GUI com Capture and Replay. A abordagem utiliza técnicas de Machine Learning para treinar classificadores que são usados para detetar automaticamente a presença de uma Gate GUI (neste documento chamado de ponto de blo-queio). Nesta situação, o utilizador pode intervir para desbloquear a Gate GUI detetada inserindo uma sequência de inputs diretamente na interface da aplicação móvel. Esta interação do utiliza-dor é gravada pelo juGULAR e reproduzida sempre que a mesma Gate GUI é detetada durante a exploração. Neste estudo, foram consideradas duas classes de Gate GUIs: login e definições de rede.

A iMPAcT tool é uma ferramenta que explora automaticamente uma aplicação móvel An-droid de forma a identificar e testar comportamento recorrente (UI Patterns). Esta ferramenta será descrita com mais pormenor no Capítulo3.

2.6 Conclusões 21

2.6

Conclusões

Nos dias de hoje, o teste de aplicações móveis é um tema emergente devido à quantidade deste tipo de aplicações disponíveis no mercado. Por esta razão, os investigadores têm-se focado na automatização do processo de teste e têm criado diversas abordagens para garantir que estas aplicações funcionam corretamente. Este processo de teste pode ser feito a vários níveis, tais como desempenho, segurança, interface, entre outros.

A exploração dinâmica é uma técnica muito usada para garantir que uma aplicação funciona corretamente obtendo informação dessa aplicação em tempo de execução através da sua interface. Esta técnica assume ainda maior importância devido à natureza baseada em eventos das aplica-ções móveis. No entanto, a maior parte das abordagens existentes falham na exploração total da aplicação, ou porque não conseguem exercitar todos os eventos disponíveis, ou porque atingiram um ponto de bloqueio que impede que a exploração prossiga para novos estados.

Existem diversas ferramentas baseadas em exploração dinâmica de aplicações móveis, no en-tanto, muitas vezes a sua eficácia é desconhecida, isto é, não é possível ter informação sobre se a ferramenta conseguiu analisar completamente a aplicação em questão. Por esta razão, torna-se muito importante analisar a cobertura de código da aplicação de forma a conseguirmos avaliar uma técnica de exploração dinâmica. Atualmente, existem abordagens de análise de cobertura para testes do estilo caixa preta, isto é, testes que não requerem acesso direto ao código fonte e abordagens de análise de cobertura para testes do estilo caixa branca que, por outro lado, requerem acesso direto ao código fonte da aplicação.

Capítulo 3

iMPAcT tool

A iMPAcT tool [49,50,51,53,54,55] é uma ferramenta criada num trabalho de investigação anterior cujo objetivo é automatizar o processo de teste das interfaces de aplicações móveis An-droid. Esta ferramenta combina engenharia reversa com comportamento recorrente, isto é, padrões da interface. Na sua fase de exploração, caso seja identificado um comportamento recorrente, este é testado de acordo com os padrões de teste correspondentes. Caso não seja identificado nenhum comportamento recorrente, a exploração da aplicação prossegue.

O presente capítulo está dividido em cinco secções. Na Secção3.1é sumariada a abordagem geral de teste da ferramenta. Na Secção3.2 são apresentados alguns padrões presentes no catá-logo de padrões bem como os padrões de teste associados. A Secção3.3apresenta os artefactos produzidos como resultado das execuções da ferramenta. A Secção3.4descreve as principais con-tribuições que a iMPAcT tool fornece à comunidade. Finalmente, na Secção3.5são apresentadas as conclusões da análise realizada à ferramenta.

3.1

Abordagem

Como já foi referido, o objetivo da abordagem presente na ferramenta é testar comportamento recorrente (UI Patterns) existente nas aplicações móveis Android. A abordagem, suportada pela iMPAcT tool, encontra-se ilustrada no diagrama de componentes da Figura3.1.

3.1.1 Implementação

Os três componentes principais que constituem a abordagem são [51]:

• Patterns Catalogue – Contém o conjunto de UI Patterns, que devem ser identificados pela ferramenta nas aplicações móveis, e os Test Patterns associados. O utilizador, no processo de configuração do teste da aplicação, deve indicar que padrões, presentes neste catálogo,

24 iMPAcT tool

Figura 3.1: Diagrama de componentes da abordagem implementada na iMPAcT tool [53]

devem ser identificados e testados. A Secção 3.2 apresenta alguns exemplos de padrões existentes neste catálogo.

• Tool – Este componente é dividido em: 1) Explorer responsável por explorar automati-camente a aplicação móvel usando engenharia reversa; 2) Tester que contém os métodos utilizados para testar os UI Patterns identificados durante a fase de exploração.

• Platform Adaptor – Responsável por fazer a ligação entre a Tool e a aplicação que se pre-tende testar. Este componente é dividido em outros dois componentes: 1) Observer res-ponsável por obter o estado da aplicação; 2) Interactor resres-ponsável por executar eventos na aplicação móvel.

3.1.2 Fases do processo iterativo

A execução da iMPAcT tool segue um processo iterativo no qual cada iteração é constituída pelas seguintes fases [53,50,54]:

3.1 Abordagem 25

1. Exploração da aplicação em teste; 2. Identificação de UI Patterns; 3. Teste dos UI Patterns encontrados.

A responsabilidade da primeira fase pertence ao Explorer presente na Figura3.1. Nesta fase, existe uma análise do estado atual da aplicação que consiste numa leitura recursiva dos diferentes elementos presentes no seu ecrã. Após esta análise, são identificados todos os eventos que podem ser executados. Por último, é decidido que evento executar e é realizada essa execução.

Na segunda fase, após o evento decidido na fase anterior ser executado, é verificada a presença de padrões na interface da aplicação analisando novamente o estado atual da aplicação. Todos os padrões analisados nesta fase estão presentes no catálogo da ferramenta.

A terceira e última fase apenas é iniciada quando um ou mais padrões são detetados na fase anterior. Esta fase consiste em aplicar os Test Patterns, presentes no catálogo de padrões, cor-respondentes aos UI Patterns identificados. Aplicar um Test Pattern consiste em verificar se a pré-condição do teste é verdadeira e, caso seja, executar as ações necessárias fazendo, no final, um conjunto de verificações.

Um fator importante na fase de exploração são os eventos que a ferramenta tem capacidade para executar. Atualmente, os eventos da interface do utilizador que estão implementados na ferramenta são: click, check, long click, edit e scroll [53].

No fim do processo de teste, são produzidos artefactos com informação sobre a execução da ferramenta. Estes artefactos são descritos na Secção3.3.

3.1.3 Modos de exploração

A ferramenta implementa diferentes modos relativamente à decisão do evento a executar na fase de exploração. Para isto, o utilizador necessita de definir, na interface da ferramenta, o modo que pretende que seja usado neste processo de decisão. Atualmente, existem quatros modos dis-poníveis que são [53]:

• Execute once – Cada evento apenas é executado uma vez, ou seja, caso um evento já tenha sido executado nunca mais será considerado para nova execução.

• Priority to not executed – Tal como o anterior, este modo dá prioridade a eventos que ainda não tenham sido executados. Num dado estado, caso todos os eventos existentes tenham sido executados, este começa a considerar os que possam levar a estados que contenham eventos ainda não executados. Neste modo de exploração existe ainda um limite de execuções para cada evento, de forma a evitar ciclos.

• Priority to not executed and list items – Semelhante ao modo anterior, apresentando apenas duas diferenças: 1) os eventos que são executados em elementos que pertencem a uma lista têm maior prioridade que os restantes eventos; 2) o evento “click on the App button” apenas

26 iMPAcT tool

é selecionado quando não existem mais eventos disponíveis para executar. O objetivo desta estratégia é de tentar explorar ao máximo o conteúdo do ecrã atual antes de mudar para um novo ecrã.

• All events – Este modo de exploração é um modo sem restrições. Por esta razão, não existe prioridade nos eventos a escolher, pelo que a sua execução é feita de forma aleatória. Os tempos de execução da iMPAcT tool dependem do modo de exploração que foi, inicial-mente, configurado [50].

3.1.4 Condição de paragem

A iMPAcT tool irá explorar a aplicação iterativamente até uma das duas seguintes condições se verificar [53]:

• O utilizador pressionar o botão Home do dispositivo móvel, decidindo quando terminar a exploração;

• Quando, após pressionar o botão Back, surge o ecrã principal do dispositivo. Durante a exploração, este botão é pressionado numa tentativa de voltar ao ecrã anterior.

3.2

Catálogo de padrões

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) é