Universidade Federal de Pernambuco

Centro de Informatica

Graduacao em Ciencia da Computacao

Analise comparativa das abordagenspara teste de interface grafica em

dispositivos moveis

Trabalho de Graduacao

Arthur Jorge Ebrahim Wanderley

Orientador: Leopoldo Motta Teixeira

Dezembro 2019

Arthur Jorge Ebrahim Wanderley

Analise comparativa das abordagens para teste de interface grafica emdispositivos moveis

Trabalho apresentado ao Programa de Graduacaoem Ciencia da Computacao do Departamentode Informatica da Universidade Federal de Per-nambuco como requisito parcial para obtencaodo grau de Bacharel em Ciencia da Computacao.

Universidade Federal de Pernambuco - UFPECentro de Informatica

Graduacao em Ciencia da Computacao

Orientador: Leopoldo Motta Teixeira

2

Agradecimentos

Antes de mais nada gostaria de agradecer a Deus por toda a forca que ele deu etem me dado, neste e em todos os desafios da minha vida.

Agradeco a minha famılia, primeiramente minha avo, Rosecleide, por tudo queela ja fez e continua fazendo por mim. Tudo o que consegui alcancar hoje, foi gracasa ela. Agradeco tambem aos meus pais, Leandro e Suzana, aos meus irmaos, e atodos os demais familiares, que sempre acreditaram em mim.

Agradeco aos meus amigos, em especial aos que fiz durante a faculdade, portodos os trabalhos, provas bem como peladas, churrascos e afins. Voces tornaramessa jornada muito mais especial.

Ao meu orientador, Leopoldo, por todo o suporte durante a execucao destetrabalho. Sua ajuda foi de suma importancia.

E por fim, mas nao menos importante, ao projeto CIn/Motorola bem comotodos os seus colaboradores, em especial os do meu time, ADR/CV, que me deramsuporte tanto pessoal quanto profissional desde o dia em que entrei para o projeto,tornando este minha segunda casa.

3

Resumo

Testes sao parte fundamental de varios processos de desenvolvimento de software.Trazendo esta afirmacao para o contexto de testes em dispositivos moveis, os testesde interface grafica sao essenciais para garantir a qualidade de uma aplicacao. Comisso, foram surgindo varias ferramentas com o objetivo de auxiliar a execucaodestes testes. Sendo assim, este trabalho tem como objetivo realizar uma analisecomparativa entre as ferramentas de teste de GUI em dispositivos moveis, paraauxiliar possıveis interessados em testes de software e testes moveis a esolher aferramenta mais adequada aos seus problemas.

Palavras-chave: Testes de Interface Grafica, Ferramentas de teste de GUI emdispositivos moveis, Analise Comparativa.

4

Abstract

Testing is a key part of several software development processes. Bringing thisassumption to the mobile testing context, GUI tests are essential to assure thequality of an application. Hence, the goal of this paper is to perform a comparativeanalysis on the mobile GUI testing tools, in order to help potential software andmobile testing stakeholders to choose the most suitable tool to fit their issues.

Keywords: GUI testing, Mobile GUI testing tools, Comparative analysis.

5

Lista de Figuras

3.1 Visao geral do processo da ferramenta CrashScope . . . . . . . . . . 213.2 Visao geral do processo da ferramenta LAND . . . . . . . . . . . . 223.3 Interface grafica da ferramenta LAND . . . . . . . . . . . . . . . . . 233.4 Calculo do TBC da ferramenta ArcWizard . . . . . . . . . . . . . . 233.5 Modelo Navegacional da ferramenta ArcWizard . . . . . . . . . . . 243.6 Plano de testes da ferramenta ArcWizard . . . . . . . . . . . . . . . 24

4.1 Menu de configuracoes de exploracao ferramenta LAND . . . . . . . 314.2 Ilustracao do processo web da ferramenta CrashScope . . . . . . . . 32

6

Lista de Tabelas

3.1 Lista de artigos e ferramentas catalogadas pelo estudo . . . . . . . . 183.2 Lista de artigos restantes apos 1o refinamento . . . . . . . . . . . . 193.3 Lista de artigos restantes apos 2o refinamento . . . . . . . . . . . . 193.4 Lista de artigos restantes apos 3o refinamento . . . . . . . . . . . . 20

4.1 Parametros Funcionais para Comparacao das Ferramentas . . . . . 274.2 Parametros Nao-Funcionais para Comparacao das Ferramentas . . . 274.3 Analise da Ferramenta CrashScope . . . . . . . . . . . . . . . . . . 284.4 Analise da Ferramenta LAND . . . . . . . . . . . . . . . . . . . . . 294.5 Analise da Ferramenta ArcWizard . . . . . . . . . . . . . . . . . . . 304.6 Analise comparativa completa . . . . . . . . . . . . . . . . . . . . . 34

7

Sumario

1 Introducao 101.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.1.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . 111.1.2 Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . . 11

1.2 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Fundamentacao Teorica 132.1 Teste de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Teste de Interface Grafica (GUI) . . . . . . . . . . . . . . . . . . . . 14

2.2.1 Dispositivos moveis . . . . . . . . . . . . . . . . . . . . . . . 142.2.2 Modelos de exploracao de GUI . . . . . . . . . . . . . . . . 14

3 Coleta e Selecao das Ferramentas 163.1 Processo de Coleta das Ferramentas . . . . . . . . . . . . . . . . . . 163.2 Refinamento das Ferramentas Coletadas . . . . . . . . . . . . . . . 173.3 Visao Geral das Ferramentas Selecionadas . . . . . . . . . . . . . . 20

3.3.1 CrashScope . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.2 LAND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.3 ArcWizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Analise Comparativa das Ferramentas 264.1 Criterios para comparacao . . . . . . . . . . . . . . . . . . . . . . . 26

4.1.1 Criterios Funcionais . . . . . . . . . . . . . . . . . . . . . . . 264.1.1.1 CrashScope . . . . . . . . . . . . . . . . . . . . . . 264.1.1.2 LAND . . . . . . . . . . . . . . . . . . . . . . . . . 284.1.1.3 ArcWizard . . . . . . . . . . . . . . . . . . . . . . 29

4.1.2 Criterios Nao-Funcionais . . . . . . . . . . . . . . . . . . . . 304.1.2.1 Usabilidade . . . . . . . . . . . . . . . . . . . . . . 304.1.2.2 Portabilidade . . . . . . . . . . . . . . . . . . . . . 314.1.2.3 Extensibilidade . . . . . . . . . . . . . . . . . . . . 33

4.2 Comparacao das ferramentas . . . . . . . . . . . . . . . . . . . . . . 33

8

SUMARIO

4.3 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5 Conclusao 36

Bibliografia 37

9 SUMARIO

Capıtulo 1

Introducao

Segundo Sommerville[1], o teste e destinado a mostrar que um programa faz o quee proposto a fazer para descobrir os defeitos do programa antes do uso. Quandose testa o software, o programa e executado usando dados fictıcios. Os resultadosdo teste sao verificados a procura de erros, anomalias ou informacoes sobre osatributos funcionais e nao-funcionais do programa.

Teste e validacao e parte fundamental de varios processos de desenvolvimentode software, como pode ser visto no artigo de Ruparelia[2], ja que atraves destafase e possıvel encontrar eventuais falhas e/ou faltas em diversos aspetos do pro-grama, para que possam ser consertados antes de tal software entrar em operacao,reduzindo assim o custo da operacao como um todo.

Trazendo o conceito para o universo dos dispositivos moveis, a curva cadavez mais crescente da quantidade tanto de dispositivos (2.9 bilhoes, em 2019)1

como de aplicacoes denominadas mobile (2.47 milhoes)2 torna o processo de testefundamental para garantir a qualidade destes apps.

Dentre as diversas areas de testes, uma das mais impactantes para o usuariofinal e a de interface grafica. E atraves da Graphical User Interface (GUI)3 que ousuario consegue interagir com todas as funcionalidades de uma dada aplicacao.Contudo, com o aumento da quantidade e da complexidade das interfaces, um dosmaiores desafios que os testadores moveis encontram e o de conseguir cobrir todosos testes destas aplicacoes.

Com o intuito de solucionar esta dor, foram aparecendo, tanto no mundoacademico como no mundo industrial, propostas de solucao para diminuir o tempode teste bem como expandir a cobertura dos testes. O presente trabalho tem comointuito realizar uma analise comparativa entre estas ferramentas que realizam tes-

1https://www.statista.com/statistics/330695/number-of-smartphone-users-worldwide/2https://www.statista.com/statistics/276623/number-of-apps-available-in-leading-app-sto

res/3https://developer.android.com/guide/topics/ui

10

CAPITULO 1. INTRODUCAO

tes de interface grafica em aplicacoes moveis atraves de criterios de avaliacao,funcionais e nao funcionais, a fim de auxiliar os interessados em testes moveis naescolha da ferramenta que atenda melhor as suas necessidades.

1.1 Objetivos

1.1.1 Objetivo Geral

O objetivo geral deste Trabalho de Graduacao e realizar uma analise comparativaentre as ferramentas de teste de interface grafica em dispositivos moveis. Estacomparacao tem como fim servir de suporte na hora da escolha da ferramentamais adequada para resolver o problema que o interessado pretende resolver.

1.1.2 Objetivos especıficos

Este estudo tem como finalidade realizar uma analise comparativa entre algumasdas ferramentas disponıveis tanto no mundo academico como no mundo industrial.Tendo isto em vista, os objetivos especıficos deste trabalho sao:

• Estudar os principais conceitos envolvendo testes de software, testes de ce-lulares e testes de interface grafica;

• Coletar e posteriormente refinar as ferramentas disponıveis na literatura ena industria;

• Definir os criterios a serem usados para avaliacao das ferramentas seleciona-das;

• Realizar analise e conseguinte comparacao entre as ferramentas.

1.2 Estrutura do Trabalho

Este trabalho esta dividido em 4 capıtulos, e sua estrutura esta segmentada daseguinte maneira:

• Capıtulo 2 - Fundamentacao Teorica: Contem definicoes tanto sobretestes como sua utilizacao em dispositivos moveis. Tambem define o que eum teste de interface grafica, um teste automatizado, alem dos processosenvolvidos dentro destes conceitos.

11 1.1. OBJETIVOS

CAPITULO 1. INTRODUCAO

• Capıtulo 3 - Coleta e Selecao das Ferramentas: Contem todo o pro-cesso de coleta das propostas para testes em dispositivos moveis, refinamentodas ferramentas coletadas, alem de uma visao geral das ferramentas selecio-nadas para comparacao.

• Capıtulo 4 - Analise Comparativa das Ferramentas: Contem o pro-cesso de definicao dos criterios de avaliacao de cada uma das ferramentas,uma analise individual de cada ferramenta baseada nestes criterios e por fimuma comparacao das analises, onde os resultados foram expostos.

• Capıtulo 5 - Conclusao: Contem a conclusao deste trabalho.

1.2. ESTRUTURA DO TRABALHO 12

Capıtulo 2

Fundamentacao Teorica

Este capıtulo tem como objetivo apresentar a base teorica que serve como suportepara a analise e posterior comparacao e conclusoes realizadas neste trabalho.

2.1 Teste de Software

Teste, segundo a definicao do ISTQB1, e o processo presente em todas as ativi-dades do ciclo de vida de um produto, tanto estaticas quanto dinamicas, que estapreocupado com o planejamento, preparacao e avaliacao de um componente ousistema e produtos relacionados para determinar que estes satisfazem os requi-sitos especificados, para demonstrar que tais requisitos estao funcionando comoesperado e para detectar falhas.

Para Sommerville [1], o processo de teste possui duas metas distintas, sao elas:

1. Demonstrar, tanto para o desenvolvedor como para o cliente, que o softwareatende aos requisitos propostos. Para um software customizado, isso signi-fica que existe pelo menos um teste para cada requisito do documento derequisitos. Para softwares genericos, isso significa que existem testes paratodas as funcionalidades, alem das combinacoes destas funcionalidades, queserao incorporadas na release do produto.

2. Descobrir situacoes em que o comportamento do software e incorreto, inde-sejado, ou em desacordo com sua especificacao. Estas sao consequencias dedefeitos no software. O teste de defeitos se preocupa em remover comporta-mentos indesejados do sistema, tais como crashes, interacoes nao-esperadascom outros sistemas, computacoes incorretas e dados corrompidos.

1https://glossary.istqb.org/en/search/testing

13

CAPITULO 2. FUNDAMENTACAO TEORICA

2.2 Teste de Interface Grafica (GUI)

Segundo Banerjee et al.[3], teste de GUI consiste em realizar sequencias de eventos(ex: ”Clicar no botao”, ”Digitar”, ”Abrir menu”, etc.) nos Widgets2 da interfacegrafica a fim de encontrar falhas e/ou comportamentos adversos.

Todos os sistemas baseados em UI, tirando os mais triviais, possuem umaquantidade gigantesca de sequencia de eventos que podem ser executados. Todasas tecnicas de teste de interface grafica busca reduzir a quantidade de entradas,seja de maneira manual ou automatica, no intuito de viabilizar a execucao dessestestes.

2.2.1 Dispositivos moveis

Trazendo o contexto acima para o universo dos dispositivos moveis, este tipo deteste se mostra mais importante ainda, dada a gama de dispositivos disponıveispara uso, com diferentes configuracoes de tela, processamento, memoria, entreoutras.

Segundo Tramontana et al.[4], o teste manual de aplicacoes moveis pode seruma atividade bastante onerosa, tanto em tempo quanto em recursos. Alem disso,esta alta fragmentacao dos sistemas e dispositivos mobile traz o problema de ter quetestar os mesmos casos de teste em diversos dispositivos e ambientes de execucao.

A ideia do teste de interface grafica automatizado e desenvolver scripts quepossam simular interacoes de um usuario com a GUI e verificar o comportamento,o estado e o controle de fluxo da aplicacao, a fim de encontrar possıveis desvios docomportamento esperado [5]. Tanto a industria como a academia possuem grandeinteresse em criar solucoes automatizadas para a realizacao destes testes.

2.2.2 Modelos de exploracao de GUI

De acordo com Choudhary et. al. [6], conseguimos dividir as diversas abordagensde exploracao de interface grafica em tres grandes grupos, sao estes:

1. Randomica: Estrategia que, a grosso modo, apenas gera eventos UI, oque pode ser bastante ineficiente, ja que existem muitos eventos que podemser gerados. Contudo, para testes de stress, pode se mostrar como umaalternativa util. Por fim, nao possuem um criterio de parada que indique osucesso da exploracao.

2. Baseada em Modelos: Ferramentas que fazem uso de modelos de inter-face grafica, geralmente maquinas de estados finitos que possuem activities

2https://developer.android.com/guide/topics/appwidgets/overview

2.2. TESTE DE INTERFACE GRAFICA (GUI) 14

CAPITULO 2. FUNDAMENTACAO TEORICA

como estados e eventos como transicoes. Tal estrategia se mostra mais efi-caz quanto a cobertura de codigo, mais precisa, porem, a principal limitacaodesta estrategia se da pela forma como as transicoes entre estados sao feitas,deixando de levar em conta eventos que mudam o estado da aplicacao masnao alteram a GUI.

3. Sistematica: Esta estrategia busca, atraves de tecnicas mais sofisticadas,como execucao simbolica e algoritmos evolucionarios, guiar a exploracao paraareas do codigo outrora nao exploradas pelas outras estrategias. Contudo,quando comparada a estrategias randomicas, esta se mostra menos escalavel.

15 2.2. TESTE DE INTERFACE GRAFICA (GUI)

Capıtulo 3

Coleta e Selecao das Ferramentas

Para que a escolha de uma ferramenta (abordagem) para realizar testes de in-terface grafica seja a mais adequada, e necessario fazer o levantamento das fer-ramentas disponıveis e realizar um estudo sobre cada uma. Desta maneira, epossıvel fazer mensurar os benefıcios que cada uma das solucoes podera trazer aousuario/organizacao.

A escolha adequada de uma ferramenta de testes de interface grafica infere emuma melhor cobertura do codigo da aplicacao, um menor tempo de execucao, alemde uma maior chance de capturar possıveis falhas e, consequentemente, prover umdetalhamento sobre tais erros.

Para efetuar a analise comparativa neste trabalho, foram reunidos os dados eas informacoes adquiridas sobre os assuntos envolvendo testes de software, testesem dispositivos moveis e testes de interface grafica. Tambem foram catalogadosos conceitos e as caracterısticas de cada uma das ferramentas escolhidas, baseadosnos dados mencionados acima.

Esta secao do trabalho tem como intencao mostrar como foi feito o processo decoleta e refinamento das ferramentas contidas na literatura, atraves dos estudosrealizados e dos conhecimentos adquiridos.

3.1 Processo de Coleta das Ferramentas

Para embasar a escolha das ferramentas mais adequadas para o trabalho, se faznecessario explicar e detalhar o processo de coleta destas.

O processo de coleta foi iniciado com a leitura do artigo ”Automated Testingof Android Apps: A Systematic Literature Review”[7], uma revisao sistematicada literatura do ano de 2018 que trouxe um catalogo contendo diversas ferramen-tas para testes moveis, em diversas areas de teste, tais como: Interface grafica,Seguranca, Performance, entre outros.

16

CAPITULO 3. COLETA E SELECAO DAS FERRAMENTAS

O passo seguinte foi realizar um levantamento de ferramentas atraves de pesqui-sas no Google Scholar 1, buscando por termos como: ”GUI Testing”, ”Model BasedTesting”,”GUI Automation Testing”, etc. Durante esta busca, artigos ja vistosna revisao sistematica mencionada no paragrafo acima foram encontrados. Paraevitar duplicidade na hora de realizar a analise, estes artigos nao foram levadosnovamente em consideracao.

Por fim, foi selecionada uma adaptacao do artigo ”Aiding exploratory testingwith pruned GUI models” [8], que consistia inicialmente em trazer uma abordagempara testes de interface grafica em aplicacoes web. A adaptacao move esta abor-dagem para o contexto de aplicacoes mobile, tendo como finalidade ser utilizadacomo suporte na realizacao de testes exploratorios em um ambiente industrial.

Ao final desta fase de coleta das ferramentas, foram catalogadas 105 ferramen-tas, como pode ser visto na Tabela 3.1.

3.2 Refinamento das Ferramentas Coletadas

Passada a fase de coleta das ferramentas, vem a etapa de remocao daquelas quenao sao interessantes e/ou relevantes para o trabalho. O objetivo principal destetrabalho e fazer uma analise sobre as ferramentas que realizam testes de GUI emaplicacoes moveis.

Tendo isto em vista, o primeiro criterio para excluir uma ferramenta e estanao ser direcionada ao contexto mobile. Consequentemente o segundo criterio deexclusao e o trabalho analisado nao ter relacao com testes de interface grafica. ATabela 3.2 mostra que a quantidade de ferramentas a serem usadas cai considera-velmente, reduzindo o total de ferramentas para 54.

Depois deste primeiro refinamento, o proximo passo era filtrar por ferramentasefetivamente implementadas, excluindo aquelas que nao chegaram a fase de de-senvolvimento. Apos isto, tentativas de contato foram realizadas com os autoresdos artigos os quais as ferramentas nao foram disponibilizadas publicamente oua ferramenta disponibilizada possui problemas para ser executada e/ou utilizada.Os artigos cujo resposta ao contato foi nula ou negativa foram desconsiderados doestudo.

Com o refinamento quase terminado, o numero de ferramentas selecionadas ateo momento e de 18, como pode ser visto pela Tabela 3.3. Para que a comparacaoentre elas seja mais padronizada, por fim foram removidos as ferramentas conside-radas ”antigas”, ou seja, antes do ano de 2017, pois dada a rapida evolucao tantodas plataformas como das aplicacoes moveis, estudos feitos anteriormente sofremcerta defasagem em relacao aos estudos mais recentes.

1https://scholar.google.com/

17 3.2. REFINAMENTO DAS FERRAMENTAS COLETADAS

CAPITULO 3. COLETA E SELECAO DAS FERRAMENTAS

ArtigosZeng et al.[9] Packeviius et al. [10] AppACTS [11]Dagger [12] SIG-Droid [13] CAFA [14]Malisa et al. [15] Knorr et al. [16] Holzmann et al. [17]CRASHSCOPE [18] TAST [19] Guo et al. [20]MAMBA [21] IntentDroid [22] Griebe et al. [23]Pretect [24] Griebe et al. [25] PBGT [26]DroidMate [27] Farto et al. [28] Chen et al. [29]SSDA [30] MobiGUITAR [31] Banerjee et al. [32]TrimDroid [33] AGRippin [34] Amalfitano et al. [35]ERVA [36] Aktouf et al. [37] Adinata et al. [38]Clapp et al. [39] THOR [40] A5 [41]SAPIENZ [42] AppAudit [43] Suarez et al. [44]RacerDroid [45] Morgado et al. [46] Linares et al. (S/REF)Baek et al. [47] Hassanshahi et al. [48] Sasnauskas et al. [49]DiagDroid [50] iMPAcT [51] AMDetector (S/REF)MobiPlay [52] Deng et al. [53] RERAN [54]MOTIF [55] Espada et al. [56] Yang et al. (S/REF)DRUN [57] Zhang et al. [58] ORBIT (S/REF)DroidDEV [59] QUANTUM [60] DroidTest (S/REF)GAT [61] CRAXDroid [62] Appstrument (S/REF)Zhang et al. [63] IntentFuzzer [64] Dynodroid (S/REF)Jabbarvand et al. [65] Vikomir et al. [66] SPAG [67]Qian et al. [68] Shahriar et al. [69] SwiftHand [70]Ermuth et al. [71] APSET [72] A3E [73]CADAGE [74] DROIDRACER [75] Avancini et al. (S/REF)Zhang et al. [76] EvoDroid [77] Amalfitano et al. (S/REF)Zhang et al. [78] SPAG-C [79] SALES (S/REF)dLens [80] Caiipa [81] LEAKDROID (S/REF)Sonny et al. [82] UGA [83] GUIdiff (S/REF)Collider (S/REF) Mirzaei et al. [84] JPF-Android (S/REF)Mahmood et al. (S/REF) MASHTE (S/REF) Franke et al. (S/REF)Dhanapal et al. (S/REF) ACTEve (S/REF) SmartDroid (S/REF)JarJarBinks [85] TEMA [86] Sadeh et al. (S/REF)Hu et al. (S/REF) A2T2 [87] Zheng, Haibing, et al. [88]ART (S/REF) MAMBA [88] ALARic [89]CrawlDroid [90] GATOR [91] DetReduce [92]AutoDroid [93] LAND [94] Speedroid [95]AMOGA [96] ArcWizard [8]

Tabela 3.1: Lista de artigos e ferramentas catalogadas pelo estudo

3.2. REFINAMENTO DAS FERRAMENTAS COLETADAS 18

CAPITULO 3. COLETA E SELECAO DAS FERRAMENTAS

ArtigosZeng et al. [9] SIG-Droid [13] Griebe et al. [23]CRASHSCOPE [18] Farto et al. [28] PBGT [26]MAMBA [21] MobiGUITAR [31] Amalfitano et al. [35]Pretect [24] AGRippin [34] RERAN [54]TrimDroid [33] THOR [40] Yang et al. (S/REF)Clapp et al. [39] Morgado et al. [46] ORBIT (S/REF)SAPIENZ [42] iMPAcT [51] Appstrument (S/REF)Baek et al. [47] EvoDroid [77] Dynodroid (S/REF)MobiPlay [52] SPAG-C [79] SPAG [67]DroidDEV [59] UGA [83] SwiftHand [70]GAT [61] A2T2 [87] A3E [73]Zhang et al. [63] MAMBA [88] Amalfitano et al. (S/REF)Ermuth et al. [71] GATOR [91] LEAKDROID (S/REF)CADAGE [74] LAND [94] GUIdiff (S/REF)Collider (S/REF) ArcWizard [8] SmartDroid (S/REF)Dhanapal et al. (S/REF) Zheng, Haibing, et al. [88]Hu et al. (S/REF) ALARic [89]CrawlDroid [90] DetReduce [92]AutoDroid [93] Speedroid [95]AMOGA [96]

Tabela 3.2: Lista de artigos restantes apos 1o refinamento

ArtigosCRASHSCOPE [18] MobiGUITAR [31] SwiftHand [70]TrimDroid [33] AGRippin [34] LEAKDROID (S/REF)SAPIENZ [42] GATOR [91] Zheng, Haibing, et al. [88]DroidDEV [59] LAND [94] ALARic [89]AutoDroid [93] ArcWizard [8] DetReduce [92]CrawlDroid [90]

Tabela 3.3: Lista de artigos restantes apos 2o refinamento

19 3.2. REFINAMENTO DAS FERRAMENTAS COLETADAS

CAPITULO 3. COLETA E SELECAO DAS FERRAMENTAS

ArtigosCRASHSCOPE [18] LAND [94] Zheng, Haibing, et al. [88]AutoDroid [93] ArcWizard [8] ALARic [89]CrawlDroid [90] DetReduce [92]

Tabela 3.4: Lista de artigos restantes apos 3o refinamento

Ao final de todo este processo, restaram um total de 8 ferramentas a seremanalisadas, como mostra a Tabela 3.4. Dada a data de finalizacao deste traba-lho e problemas na execucao de determinadas ferramentas, um subconjunto de 3destas foi selecionado para ser destrinchado e posteriormente comparado, a saber:CrashScope, LAND e ArcWizard.

3.3 Visao Geral das Ferramentas Selecionadas

Tendo como base o refinamento feito na secao anterior, esta secao ira trazer aoleitor um resumo de cada uma das ferramentas escolhidas, para que entao, noproximo capıtulo, elas sejam comparadas.

3.3.1 CrashScope

A ferramenta CrashScope foi desenvolvida pelo grupo de pesquisa SEMERU 2,da universidade de William & Mary (Virgınia, EUA), em conjunto com outroscolaboradores, tendo sua primeira versao lancada em 2016 [18] e aprimorada em2017 [97].

O processo da ferramenta, como mostra a Figura 3.1, inicia-se com o usuario in-serindo o Android Application Package (APK)3 e a configuracao de estrategias queo CrashScope ira explorar. Com o artefato em maos, a ferramenta primeiramenteextrai possıveis contextos para os usar durante a fase de execucao sistematica daaplicacao, feita em um Android Virtual Device (AVD)4, alem de outros parametros.Caso ocorram erros, excecoes e/ou crashes, o CrashScope salva dinamicamente aexecucao em um banco de dados proprio, incluindo detalhes sobre as acoes reali-zadas durante a exploracao.

Passada a fase de execucao, as informacoes contidas no banco de dados doCrashScope sao analisadas e processadas pelo Gerador de Reports em LinguagemNatural da ferramenta, que tem como resultado um relatorio em HTML com odetalhamento das falhas encontradas. Alem disso, as ferramentas de geracao e

2https://www.android-dev-tools.com/3https://en.wikipedia.org/wiki/Android application package4https://developer.android.com/studio/run/managing-avds

3.3. VISAO GERAL DAS FERRAMENTAS SELECIONADAS 20

CAPITULO 3. COLETA E SELECAO DAS FERRAMENTAS

reproducao de crashes durante a execucao criam e reproduzem, respectivamente,scripts Android Debug Bridge(ADB)5, a fim de dar mais informacoes para que afalha seja descoberta.

Figura 3.1: Visao geral do processo da ferramenta CrashScope

Atualmente o CrashScope esta publicamente disponıvel no site de ferramentaspara desenvolvedores Android6, porem, ate o dia da finalizacao deste trabalho,esta encontra-se em manutencao. Portanto, as funcionalidades da ferramenta estaolimitadas.

3.3.2 LAND

A ferramenta LAND[94] foi desenvolvida por um grupo da University of the Chi-nese Academy of Sciences (UCAS) em 2018, com o intuito de trazer ao usuariouma abordagem ”amigavel”, segundo os autores do artigo, para realizar testes deGUI sem que haja perda de eficiencia na exploracao das interfaces graficas dasaplicacoes.

O processo da ferramenta, como mostra a Figura 3.2, e dividida em quatromodulos principais: o primeiro modulo e o de Pre-processamento, onde a aplicacaode entrada e instrumentada, em byte-code, e o perfil de exploracao e automatica-mente criado de acordo com as features desta aplicacao.

O segundo modulo e o de exploracao de GUI, que realiza um loop para atualizaro modelo de transicao de paginas, chamado pelos autores do artigo de ”LATTE”,que se divide em: escolher e executar um evento, monitorar o estado da aplicacaoe abstrair e construir o novo modelo de transicao.

Com as informacoes do modulo acima, a geracao de testes, terceiro modulo,vai reusando o modelo construıdo a fim de gerar casos de teste, podendo fazer uso

5https://developer.android.com/studio/command-line/adb6https://www.android-dev-tools.com/crashscope

21 3.3. VISAO GERAL DAS FERRAMENTAS SELECIONADAS

CAPITULO 3. COLETA E SELECAO DAS FERRAMENTAS

de cinco estrategias diferentes, sendo elas: Direcionada a Activity 7, Direcionada aWidget8, Direcionada a Label, Travessia do modelo navegacional da GUI e Record-and-Replay.

Por fim, o modulo de geracao de reports retorna ao usuario relatorios tantosobre a cobertura de codigo do APK e como sobre as falhas e/ou crashes queaconteceram durante a exploracao.

Figura 3.2: Visao geral do processo da ferramenta LAND

Atualmente a ferramenta esta publicamente disponıvel em um repositorio GIT 9.A interface da ferramenta, como pode ser vista na Figura 3.3, disponibiliza aousuario uma vasta customizacao de parametros de exploracao, bem como conse-gue mostrar, atraves de Call graphs, o modelo a ser explorado em tempo real.

3.3.3 ArcWizard

A ferramenta ArcWizard e uma adaptacao de um artigo construıdo por um grupoda Universidade Federal de Pernambuco (UFPE) [8], a fim de trazer a solucaoproposta para o ambiente dos dispositivos moveis, mais especificamente o contextode testes exploratorios em um ambiente industrial.

O processo da ferramenta inicia com o upload de duas versoes de uma dadaaplicacao, uma mais antiga e uma mais recente. Com essas duas aplicacoes emmaos, o ArcWizard primeiramente faz o calculo do TBC - To Be Covered (como

7https://developer.android.com/reference/android/app/Activity8https://developer.android.com/guide/topics/appwidgets9https://github.com/hanada31/LAND

3.3. VISAO GERAL DAS FERRAMENTAS SELECIONADAS 22

CAPITULO 3. COLETA E SELECAO DAS FERRAMENTAS

Figura 3.3: Interface grafica da ferramenta LAND

pode ser visto da Figura 3.4), ou seja, da quantidade de metodos que foram mo-dificados de uma versao para outra da mesma aplicacao.

Figura 3.4: Calculo do TBC da ferramenta ArcWizard

Feito o calculo acima, o plano de teste e criado baseado no modelo navega-cional da aplicacao (vide Figura 3.5). Cada um dos casos deste plano de testee mostrado ao usuario em linguagem natural (Figura 3.6). Uma vez gerado esteplano, o usuario consegue iniciar os testes exploratorios. Contudo, a versao atualda ferramenta nao realiza os testes de maneira automatica, ficando a cargo dotestador seguir os passos de cada um dos casos de teste da suıte.

23 3.3. VISAO GERAL DAS FERRAMENTAS SELECIONADAS

CAPITULO 3. COLETA E SELECAO DAS FERRAMENTAS

Entretanto, e possıvel acompanhar a cobertura que a ferramenta alcanca emtempo real, bem como capturar screenshots da UI durante a execucao de cadaum dos passos. Para isso, o usuario precisa conectar o dispositivo no computador,via USB e instalar programas auxiliares, bem como o APK instrumentado peloArcWizard.

[b]0.4

Figura 3.5: Modelo Navegacional da ferramenta ArcWizard

[b]0.4

Figura 3.6: Plano de testes da ferramenta ArcWizard

Por se tratar de uma solucao para a industria, o ArcWizard nao e disponıvelpublicamente. Sua interface simples e intuitiva permite ao usuario rodar a ferra-

3.3. VISAO GERAL DAS FERRAMENTAS SELECIONADAS 24

CAPITULO 3. COLETA E SELECAO DAS FERRAMENTAS

menta sem ter um conhecimento mais profundo dos conceitos de execucao, alemda possibilidade de controlar a cobertura de cada execucao, bem como de reportareventuais falhas e/ou crashes.

25 3.3. VISAO GERAL DAS FERRAMENTAS SELECIONADAS

Capıtulo 4

Analise Comparativa dasFerramentas

O objetivo deste capıtulo e realizar uma analise comparativa dentre as ferramen-tas selecionadas apos todo o processo feito no Capıtulo 3 desta monografia. Seraolevados em conta aspectos funcionais e nao-funcionais, onde cada uma das ferra-mentas terao seus pros e contras detalhados na Secao 4.1. Por fim, na Secao 4.2,sera desenhada uma conclusao baseada na comparacao realizada durante todo estecapıtulo.

4.1 Criterios para comparacao

Tomando como base os requisitos das ferramentas de teste de interface graficaselecionadas, bem como as caracterısticas vindas da literatura, os criterios paracomparacao foram definidos e podem ser vistos na Tabela 4.1.

Alem destes parametros definidos acima, tambem foram definidos criterios decomparacao Nao-funcionais para uma melhor avaliacao das ferramentas. Taiscriterios podem ser vistos na Tabela 4.2.

4.1.1 Criterios Funcionais

4.1.1.1 CrashScope

A ferramenta CrashScope, desde o lancamento de sua segunda versao [97], estadisponıvel publicamente na sua versao web, onde o usuario consegue criar e moni-torar uma ou mais execucoes e receber os resultados destas. Quanto ao numerode artefatos que a ferramenta solicita ao usuario, pela ferramenta nao realizar ne-nhum comparativo entre versoes de uma mesma aplicacao, so se faz necessario ouso do APK mais recente da aplicacao.

26

CAPITULO 4. ANALISE COMPARATIVA DAS FERRAMENTAS

Parametro FuncionalPlataforma WebInterface GraficaNo de ArtefatosInstrumentacao

AVD/Dispositivo externoBaseado em ContextoExploracao de GUI

Execucao dos Casos de TesteCasos de Teste Reproduzıveis

Relatorios de Falha

Tabela 4.1: Parametros Funcionais para Comparacao das Ferramentas

Parametro Nao-FuncionalUsabilidade

PortabilidadeExtensibilidade

Tabela 4.2: Parametros Nao-Funcionais para Comparacao das Ferramentas

No quesito instrumentacao, o CrashScope nao realiza nenhum tipo de pre-processamento da aplicacao a ser explorada a nao ser a analise de contexto, queconsiste em encontrar Activities1 que possuem algum tipo de feature contextual,ou seja, relacionada a conectividade (Wi-Fi, Bluetooth, etc.) e/ou sensores (ace-lerometro, GPS, entre outros), para que posteriormente sejam realizadas mudancasde contexto na aplicacao, por exemplo, desligando o Wi-Fi durante a exploracao,para procurar por possıveis falhas.

Quanto ao uso de AVD ou Dispositivos externos, a ultima versao do CrashScopeeximiu do usuario a necessidade de pre-configurar um ambiente, real ou virtual,para realizar a exploracao, pois conta com um conjunto proprio de AVDs e dispo-sitivos fısicos a disposicao, como pode ser visto na Figura 4.2.

O sistema de exploracao desta ferramenta e sistematica, ou seja, as acoes toma-das sao definidas atraves de uma heurıstica pre-definida. No caso do CrashScope,sao utilizadas tres heurısticas principais, que se combinam na hora da execucao:

• A direcao da exploracao (Top-Down ou Bottom-Up);

• O tipo de entrada a ser gerado nos campos de texto (Sem texto, Textoesperado, Texto nao-esperado);

1https://developer.android.com/reference/android/app/Activity

27 4.1. CRITERIOS PARA COMPARACAO

CAPITULO 4. ANALISE COMPARATIVA DAS FERRAMENTAS

Parametro CrashScopePlataforma Web XInterface Grafica XNo de Artefatos 1Instrumentacao X

AVD/Dispositivo externo XBaseado em Contexto XExploracao de GUI Sistematica

Execucao dos Casos de Teste AutomaticaCasos de Teste Reproduzıveis X

Relatorios de Falha X

Tabela 4.3: Analise da Ferramenta CrashScope

• Habilitar ou nao o teste de contexto adverso, ou seja, nao esperado pelaaplicacao (Ex: Wi-Fi desligado quando a aplicacao espera que este estejaligado).

A execucao dos casos de teste e automatica, pois nao se faz necessario nenhumaacao externa do usuario para configurar, iniciar e/ou finalizar uma execucao. Du-rante esta exploracao, qualquer caminho que leve a uma falha e/ou crash daaplicacao sera detalhadamente guardado em um banco de dados da ferramenta,para que, posteriormente, outros dois modulos do CrashScope gerem, respecti-vamente: um relatorio, em HTML, baseado em linguagem natural, contendo ospassos para reproducao da falha; sequencias de scritps ADB reproduzıveis con-tendo os casos de teste que apresentaram falhas.

A Tabela 4.3 mostra o resultado da analise sobre a ferramenta CrashScope.

4.1.1.2 LAND

A ferramenta LAND esta publicamente disponıvel para Desktop, atraves de um exe-cutavel JAVA2, que atualmente funciona apenas em dispositivos Windows. Parautilizar a aplicacao, se faz necessario ainda realizar a instalacao de alguns progra-mas auxiliares, dos quais a aplicacao faz uso. Quanto ao numero de artefatos quea ferramenta solicita ao usuario, pela ferramenta nao realizar nenhum comparativoentre versoes de uma mesma aplicacao, so se faz necessario o uso do APK maisrecente da aplicacao.

No quesito instrumentacao, a LAND faz uso deste passo apenas para umaposterior contabilizacao de cobertura da exploracao. Quanto ao uso de AVDs ou

2https://www.java.com

4.1. CRITERIOS PARA COMPARACAO 28

CAPITULO 4. ANALISE COMPARATIVA DAS FERRAMENTAS

Parametro LANDPlataforma Web XInterface Grafica XNo de Artefatos 1Instrumentacao X

AVD/Dispositivo externo XBaseado em Contexto XExploracao de GUI Model-Based

Execucao dos Casos de Teste AutomaticaCasos de Teste Reproduzıveis X

Relatorios de Falha X

Tabela 4.4: Analise da Ferramenta LAND

Dispositivos externos, o usuario precisa configurar um device, real ou virtual, nocomputador (via USB), para que o aplicativo instrumentado seja instalado e paraque os testes sejam executados.

O sistema de exploracao da ferramenta e baseado em modelos e e chamadode modelo ”LATTE” pelos autores do artigo, funcionando da seguinte maneira:Um modelo vazio e iniciado, um evento e executado, e as informacoes dos Widgetssao catalogadas juntamente com os scripts relacionados a este elemento. Com asinformacoes acima e com os logs da instrumentacao um novo modelo e criado euma nova iteracao e realizada. Esse procedimento e realizado ate que todos oseventos sejam realizados.

Os casos de teste sao gerados de maneira incremental, juntamente com asiteracoes do modelo. A ferramenta tambem disponibiliza ao usuario criar osproprios scripts de teste, caso queira validar algum requisito especıfico.

A execucao dos testes e automatica, e ao fim desta, e retornado ao usuario doisrelatorios: de cobertura, onde os metodos cobertos pela exploracao sao evidencia-dos; de falha, onde as excecoes sao detalhadas e o script ADB que foi executado eque gerou tal erro.

A Tabela 4.4 mostra o resultado da analise sobre a ferramenta LAND.

4.1.1.3 ArcWizard

O ArcWizard, por ser uma adaptacao para a industria de um artigo, esta disponıvelapenas no escopo da empresa na sua versao web, onde o usuario consegue fazer todoo fluxo de exploracao de uma ou mais aplicacoes. Quanto ao numero de artefatosque a ferramenta solicita, por se tratar de uma abordagem que visa testar apenasas mudancas de uma versao de um aplicativo para outro, o usuario precisa inserirna ferramenta duas versoes: uma mais antiga e uma mais recente.

29 4.1. CRITERIOS PARA COMPARACAO

CAPITULO 4. ANALISE COMPARATIVA DAS FERRAMENTAS

Parametro ArcWizardPlataforma Web XInterface Grafica XNo de Artefatos 2Instrumentacao X

AVD/Dispositivo externo XBaseado em Contexto XExploracao de GUI Model-Based

Execucao dos Casos de Teste ManualCasos de Teste Reproduzıveis X

Relatorios de Falha X

Tabela 4.5: Analise da Ferramenta ArcWizard

O sistema de exploracao desta ferramenta e baseado em modelo, funcionandoda seguinte maneira: Primeiramente, e realizado um calculo do TBC (To Be Cove-red), que retorna todas as partes da aplicacao que sofreram algum tipo de mudancade uma versao para outra. Apos isto, e gerado o modelo navegacional da aplicacao,para que entao os casos de teste sejam criados e colocados dentro de uma suıte detestes.

Para iniciar a execucao de uma suıte de testes, atualmente, nao ha nenhumsuporte automatico, ou seja, o usuario precisa realizar o passo a passo de cada umdos testes da suıte de maneira manual.Contudo, e possıvel acompanhar em temporeal a cobertura, quanto a quantidade de metodos, do ArcWizard, bem comoreceber capturas de tela referentes a cada caso de teste que esta sendo executado.Para tal, e necessario o usuario conectar o dispositivo ao computador via USB,instalar APKs auxiliares e executar os testes mantendo o dispositivo conectado.

Durante a execucao, caso o testador encontre falhas e/ou crashes, e possıvelabrir Change Requests (CRs)3, com passo a passo detalhado juntamente com cap-turas de tela, diretamente no sistema de Issue Tracker 4 da companhia.

A Tabela 4.5 mostra o resultado da analise sobre a ferramenta ArcWizard.

4.1.2 Criterios Nao-Funcionais

4.1.2.1 Usabilidade

Segundo a International Organization for Standardization (ISO), usabilidade e oparametro que mede a efetividade, eficiencia e satisfacao de um produto com

3https://en.wikipedia.org/wiki/Change request4https://en.wikipedia.org/wiki/Issue tracking system

4.1. CRITERIOS PARA COMPARACAO 30

CAPITULO 4. ANALISE COMPARATIVA DAS FERRAMENTAS

objetivos especıficos em um contexto especıfico.5

Neste quesito, todas as ferramentas sao equivalentes tanto quanto a efetividade,pois todas entregam um fluxo o qual o usuario consegue completar, como quanto asatisfacao, ja que ambas as ferramentas conseguem entregar ao usuario o resultadoda exploracao da interface grafica, de maneira bastante detalhada.

Contudo, no quesito eficiencia, a ferramenta LAND se mostra abaixo das de-mais por possuir um processo mais complexo e customizavel para o usuario seguir,por exemplo, na hora de iniciar a exploracao, como pode ser visto na Figura 4.1.

Entre a CrashScope e a ArcWizard, a segunda fica em desvantagem por ne-cessitar de interacao humana durante a fase de execucao e sinalizacao de falhasdos testes exploratorios. A CrashScope necessita apenas do APK para realizartodo o processo, incluindo a criacao dos Android Virtual Devices (AVDs)6 para aexecucao dos testes, como mostra a Figura 4.2.

Figura 4.1: Menu de configuracoes de exploracao ferramenta LAND

4.1.2.2 Portabilidade

De acordo com a ISO91267, portabilidade e o parametro que mede a capacidadede um sistema de migrar para uma outra plataforma. Para esta comparacao,sera medido a facilidade do usuario utilizar a ferramenta em diferentes sistemasoperacionais.

As ferramentas ArcWizard e CrashScope saem na frente neste quesito, poisestao disponibilizados em sistemas web, que permitem ao usuario fazer uso destas

5https://www.iso.org/obp/ui/#iso:std:iso:9241:-11:ed-2:v1:en6https://developer.android.com/studio/run/managing-avds7https://www.iso.org/obp/ui/#iso:std:iso-iec:25010:ed-1:v1:en

31 4.1. CRITERIOS PARA COMPARACAO

CAPITULO 4. ANALISE COMPARATIVA DAS FERRAMENTAS

Figura 4.2: Ilustracao do processo web da ferramenta CrashScope

4.1. CRITERIOS PARA COMPARACAO 32

CAPITULO 4. ANALISE COMPARATIVA DAS FERRAMENTAS

ferramentas em qualquer sistema operacional, sem realizar quaisquer configuracoesde ambiente, pois tudo e feito dentro do servidor que recebe os dados vindo destesistema.

A ferramenta LAND necessita de uma preparacao de ambiente a ser realizadapelo usuario, pois o processo roda localmente na maquina do cliente.

4.1.2.3 Extensibilidade

Este requisito se refere a capacidade do sistema de manipular uma versao cres-cente do trabalho de maneira uniforme, ou seja, estar preparada para crescer [98].Para realizar esta comparacao, sera medida a capacidade da ferramenta de receberincrementacoes.

Dentre as ferramentas selecionadas, a CrashScope e quem fica para tras nestequesito, pois alem de se encontrar em uma versao estavel (mesmo que em manu-tencao) desde 2017, o modelo de exploracao sistematico que ela implementa naopermite uma escalabilidade tao grande quanto as outras.

Entre a LAND e a ArcWizard, a segunda sai na frente, pois ja existem ini-ciativas de acoplar outras ferramentas a ela, como por exemplo a de execucaoautomatica dos casos de teste, bem como a de catalogacao automatica de falhas.A LAND aparenta, dada a conclusao do autor, em ter chegado no seu ponto desaturacao, onde apenas o melhorias no modelo de exploracao pretendem ser reali-zadas.

4.2 Comparacao das ferramentas

Apos todo o processo de coleta, refinamento e analise de cada uma das ferramen-tas, vem a fase de realizar um comparativo entre as ferramentas selecionadas. ATabela 4.6 traz a juncao da analise dos criterios funcionais de todas as ferramentasanalisadas.

A primeira conclusao que pode ser tirada apos realizar a comparacao das fer-ramentas e de que nao existe uma ferramenta que possa ser considerada como amelhor e/ou mais completa, pois mesmo todas sendo solucoes para testes de inter-face grafica em dispositivos moveis, cada uma possui um objetivo final especıfico,e isso influi desde o processo de montagem dos casos de teste ate o modelo dosrelatorios da exploracao.

A segunda conclusao e de que podemos extrair pontos fortes e fracos de cadauma das ferramentas, usando como espelho as demais. No caso do CrashScope, porse tratar de uma ferramenta cujo modelo de exploracao e sistematica e os testessao feitos principalmente forcando a aplicacao a diferentes contextos, esperadose inesperados, acaba nao conseguindo testar outros aspectos os quais as demais

33 4.2. COMPARACAO DAS FERRAMENTAS

CAPITULO 4. ANALISE COMPARATIVA DAS FERRAMENTAS

Parametro CrashScope LAND ArcWizardPlataforma Web X X XInterface Grafica X X XNo de Artefatos 1 1 2Instrumentacao X X X

AVD/Dispositivo externo X X XBaseado em Contexto X X XExploracao de GUI Sistematica Model-Based Model-based

Execucao dos Casos de Teste Automatica Automatica ManualCasos de Teste Reproduzıveis X X X

Relatorios de Falha X X X

Tabela 4.6: Analise comparativa completa

ferramentas abrangem. Contudo, a ferramenta se mostra muito mais atrativaaquele usuario que nao possui experiencia em teste de software, pois requer poucoconhecimento previo e os relatorios de falha estao a nıvel de linguagem natural.

Ja a ferramenta LAND, ao contrario das concorrentes, possui um processo ondeo usuario pode configurar praticamente todos os passos do processo da ferramenta,tornando-a mais atraente a usuarios com mais experiencia, e tornando a ferramentautil a diversos tipos de finalidade. Quanto aos pontos de melhoria, baseado naexperiencia dos concorrentes, a ferramenta poderia prover ao usuario um processomais simples de configuracao, podendo ate migrar seu sistema para uma versao web,para assim abranger uma maior quantidade de sistemas operacionais suportados.

Por fim, a ArcWizard tem como ponto forte a criacao de casos de teste baseadonas mudancas feitas entre versoes de uma mesma aplicacao, algo nao encontradoem nenhum dos 105 artigos analisados. Esta funcionalidade se mostra muito util nahora da execucao de testes exploratorios em um ambiente de integracao contınua,pois testar a aplicacao inteira e uma atividade custosa a organizacao. Contudo,como pontos de melhoria, a ferramenta poderia integrar tanto um processo au-tomatizado para a fase de execucao dos casos de teste bem como gerar casos deteste reproduzıveis, este ultimo para aprimorar, consequentemente, o processo deabertura de Change Requests (CRs).

4.3 Consideracoes Finais

Neste capıtulo, usando como base o estudo realizado no capıtulo anterior, definiucriterios para a avaliacao de cada uma das ferramentas selecionadas, tanto funci-onais como nao-funcionais. Apos isto, cada uma das ferramentas foi avaliada deacordo com os criterios pre-definidos e por fim uma comparacao destas foi reali-

4.3. CONSIDERACOES FINAIS 34

CAPITULO 4. ANALISE COMPARATIVA DAS FERRAMENTAS

zada e conclusoes juntamente com os pontos fortes bem com os pontos de melhoriade cada solucao foram levantados.

35 4.3. CONSIDERACOES FINAIS

Capıtulo 5

Conclusao

O principal objetivo deste trabalho foi realizar uma analise comparativa entre abor-dagens para testes de interface grafica em dispositivos moveis. Durante o cursodeste trabalho, os conceitos de teste de software e testes em dispositivos moveisforam definidos para um melhor entendimento do processo de teste de interfacegrafica em dispositivos moveis bem como suas principais caracterısticas. Apos estafase, foi exposto todo o processo de coleta e refinamento das ferramentas, onde to-dos os criterios para fundamentar a escolha das mais relevantes ao estudo forambem definidos. Apos isto, todas as ferramentas selecionadas foram apresentadas aoleitor atraves de uma pequena introducao. Por conseguinte, os criterios para ava-liacao foram definidos, cada uma das ferramentas passou por uma analise baseadanestes criterios e por fim foi realizada uma comparacao entre estas ferramentas.

As principais dificuldades encontradas durante a execucao deste trabalho estaorelacionadas ao entendimento e posterior classificacao dos artigos coletados, alemda alta quantidade de artigos a serem analisados e a falta de feedback/documentacaode varios autores de ferramentas. Alem desta, um outro ponto importante a se le-var em consideracao foi a dificuldade na escolha tanto dos criterios de refinamentocomo dos criterios de avaliacao das ferramentas selecionadas.

36

Bibliografia

[1] I. Sommerville, “Software engineering 9th Edition”, ISBN-10137035152, 2011.

[2] N. B. Ruparelia, “Software development lifecycle models”, ACM SIGSOFTSoftware Engineering Notes, v. 35, n. 3, pp. 8–13, 2010.

[3] I. Banerjee, B. Nguyen, V. Garousi e A. Memon, “Graphical user interface(GUI) testing: Systematic mapping and repository”, Information and Soft-ware Technology, v. 55, n. 10, pp. 1679–1694, 2013.

[4] P. Tramontana, D. Amalfitano, N. Amatucci e A. R. Fasolino, “Automa-ted functional testing of mobile applications: a systematic mapping study”,Software Quality Journal, v. 27, n. 1, pp. 149–201, 2019.

[5] M. Kropp e P. Morales, “Automated GUI testing on the Android platform”,on Testing Software and Systems: Short Papers, p. 67, 2010.

[6] S. R. Choudhary, A. Gorla e A. Orso, “Automated test input generationfor android: Are we there yet?(e)”, em 2015 30th IEEE/ACM Internati-onal Conference on Automated Software Engineering (ASE), IEEE, 2015,pp. 429–440.

[7] P. Kong, L. Li, J. Gao, K. Liu, T. F. Bissyande e J. Klein, “Automatedtesting of android apps: A systematic literature review”, IEEE Transactionson Reliability, v. 68, n. 1, pp. 45–66, 2018.

[8] J. Reis e A. Mota, “Aiding exploratory testing with pruned GUI models”,Information Processing Letters, v. 133, pp. 49–55, 2018.

[9] X. Zeng, D. Li, W. Zheng, F. Xia, Y. Deng, W. Lam, W. Yang e T. Xie,“Automated test input generation for android: Are we really there yet in anindustrial case?”, em Proceedings of the 2016 24th ACM SIGSOFT Inter-national Symposium on Foundations of Software Engineering, ACM, 2016,pp. 987–992.

[10] S. Packevicius, A. Usaniov, S. Stanskis e E. Bareisa, “The testing methodbased on image analysis for automated detection of UI defects intended formobile applications”, em International Conference on Information and Soft-ware Technologies, Springer, 2015, pp. 560–576.

37

BIBLIOGRAFIA

[11] J.-f. Huang, “AppACTS: Mobile app automated compatibility testing ser-vice”, em 2014 2nd IEEE International Conference on Mobile Cloud Com-puting, Services, and Engineering, IEEE, 2014, pp. 85–90.

[12] C. Yang, G. Yang, A. Gehani, V. Yegneswaran, D. Tariq e G. Gu, “Usingprovenance patterns to vet sensitive behaviors in Android apps”, em Inter-national Conference on Security and Privacy in Communication Systems,Springer, 2015, pp. 58–77.

[13] N. Mirzaei, H. Bagheri, R. Mahmood e S. Malek, “Sig-droid: Automatedsystem input generation for android applications”, em 2015 IEEE 26th In-ternational Symposium on Software Reliability Engineering (ISSRE), IEEE,2015, pp. 461–471.

[14] C.-H. Hsiao, J. Yu, S. Narayanasamy, Z. Kong, C. L. Pereira, G. A. Pokam,P. M. Chen e J. Flinn, “Race detection for event-driven mobile applications”,ACM SIGPLAN Notices, v. 49, n. 6, pp. 326–336, 2014.

[15] L. Malisa, K. Kostiainen, M. Och e S. Capkun, “Mobile application imper-sonation detection using dynamic user interface extraction”, em EuropeanSymposium on Research in Computer Security, Springer, 2016, pp. 217–237.

[16] K. Knorr e D. Aspinall, “Security testing for Android mHealth apps”, em2015 IEEE Eighth International Conference on Software Testing, Verifica-tion and Validation Workshops (ICSTW), IEEE, 2015, pp. 1–8.

[17] C. Holzmann e P. Hutflesz, “Multivariate testing of native mobile applica-tions”, em Proceedings of the 12th International Conference on Advances inMobile Computing and Multimedia, ACM, 2014, pp. 85–94.

[18] K. Moran, M. Linares-Vasquez, C. Bernal-Cardenas, C. Vendome e D. Poshy-vanyk, “Automatically discovering, reporting and reproducing android appli-cation crashes”, em 2016 IEEE international conference on software testing,verification and validation (icst), IEEE, 2016, pp. 33–44.

[19] B. Jiang, P. Chen, W. K. Chan e X. Zhang, “To what extent is stress testingof Android tv applications automated in industrial environments?”, IEEETransactions on Reliability, v. 65, n. 3, pp. 1223–1239, 2015.

[20] C. Guo, J. Xu, H. Yang, Y. Zeng e S. Xing, “An automated testing ap-proach for inter-application security in Android”, em Proceedings of the 9thinternational workshop on automation of software test, ACM, 2014, pp. 8–14.

[21] J. C. J. Keng, L. Jiang, T. K. Wee e R. K. Balan, “Graph-aided directedtesting of Android applications for checking runtime privacy behaviours”, emProceedings of the 11th International Workshop on Automation of SoftwareTest, ACM, 2016, pp. 57–63.

BIBLIOGRAFIA 38

BIBLIOGRAFIA

[22] R. Hay, O. Tripp e M. Pistoia, “Dynamic detection of inter-application com-munication vulnerabilities in Android”, em Proceedings of the 2015 Interna-tional Symposium on Software Testing and Analysis, ACM, 2015, pp. 118–128.

[23] T. Griebe e V. Gruhn, “A model-based approach to test automation forcontext-aware mobile applications”, em Proceedings of the 29th Annual ACMSymposium on Applied Computing, ACM, 2014, pp. 420–427.

[24] Y. Kang, Y. Zhou, M. Gao, Y. Sun e M. R. Lyu, “Experience report: De-tecting poor-responsive ui in android applications”, em 2016 IEEE 27th In-ternational Symposium on Software Reliability Engineering (ISSRE), IEEE,2016, pp. 490–501.

[25] T. Griebe, M. Hesenius e V. Gruhn, “Towards automated UI-tests for sensor-based mobile applications”, em International Conference on Intelligent Soft-ware Methodologies, Tools, and Techniques, Springer, 2015, pp. 3–17.

[26] P. Costa, A. C. Paiva e M. Nabuco, “Pattern based gui testing for mobileapplications”, em 2014 9th International Conference on the Quality of In-formation and Communications Technology, IEEE, 2014, pp. 66–74.

[27] K. Jamrozik, P. von Styp-Rekowsky e A. Zeller, “Mining sandboxes”, emProceedings of the 38th International Conference on Software Engineering,ACM, 2016, pp. 37–48.

[28] G. de Cleva Farto e A. T. Endo, “Evaluating the model-based testing appro-ach in the context of mobile applications”, Electronic notes in Theoreticalcomputer science, v. 314, pp. 3–21, 2015.

[29] X. Chen e Z. Xu, “Towards Automatic Consistency Checking between WebApplication and its Mobile Application.”, em SEKE, 2014, pp. 53–58.

[30] Y. Hu e I. Neamtiu, “Fuzzy and cross-app replay for smartphone apps”, em2016 IEEE/ACM 11th International Workshop in Automation of SoftwareTest (AST), IEEE, 2016, pp. 50–56.

[31] D. Amalfitano, A. R. Fasolino, P. Tramontana, B. D. Ta e A. M. Memon,“MobiGUITAR: Automated model-based testing of mobile apps”, IEEE soft-ware, v. 32, n. 5, pp. 53–59, 2014.

[32] A. Banerjee, L. K. Chong, S. Chattopadhyay e A. Roychoudhury, “Detec-ting energy bugs and hotspots in mobile apps”, em Proceedings of the 22ndACM SIGSOFT International Symposium on Foundations of Software En-gineering, ACM, 2014, pp. 588–598.

39 BIBLIOGRAFIA

BIBLIOGRAFIA

[33] N. Mirzaei, J. Garcia, H. Bagheri, A. Sadeghi e S. Malek, “Reducing com-binatorics in GUI testing of android applications”, em 2016 IEEE/ACM38th International Conference on Software Engineering (ICSE), IEEE, 2016,pp. 559–570.

[34] D. Amalfitano, N. Amatucci, A. R. Fasolino e P. Tramontana, “AGRippin:a novel search based testing technique for Android applications”, em Procee-dings of the 3rd International Workshop on Software Development Lifecyclefor Mobile, ACM, 2015, pp. 5–12.

[35] D. Amalfitano, N. Amatucci, A. R. Fasolino, U. Gentile, G. Mele, R. Nar-done, V. Vittorini e S. Marrone, “Improving code coverage in android appstesting by exploiting patterns and automatic test case generation”, em Pro-ceedings of the 2014 international workshop on Long-term industrial colla-boration on software engineering, ACM, 2014, pp. 29–34.

[36] Y. Hu, I. Neamtiu e A. Alavi, “Automatically verifying and reproducingevent-based races in android apps”, em Proceedings of the 25th InternationalSymposium on Software Testing and Analysis, ACM, 2016, pp. 377–388.

[37] T. Zhang, J. Gao, T. Uehara et al., “Testing location-based function servicesfor mobile applications”, em 2015 IEEE Symposium on Service-OrientedSystem Engineering, IEEE, 2015, pp. 308–314.

[38] M. Adinata e I. Liem, “A/B test tools of native mobile application”, em 2014International Conference on Data and Software Engineering (ICODSE), IEEE,2014, pp. 1–6.

[39] L. Clapp, O. Bastani, S. Anand e A. Aiken, “Minimizing GUI event traces”,em Proceedings of the 2016 24th ACM SIGSOFT International Symposiumon Foundations of Software Engineering, ACM, 2016, pp. 422–434.

[40] C. Q. Adamsen, G. Mezzetti e A. Møller, “Systematic execution of androidtest suites in adverse conditions”, em Proceedings of the 2015 InternationalSymposium on Software Testing and Analysis, ACM, 2015, pp. 83–93.

[41] T. Vidas, J. Tan, J. Nahata, C. L. Tan, N. Christin e P. Tague, “A5: Automa-ted analysis of adversarial android applications”, em Proceedings of the 4thACM Workshop on Security and Privacy in Smartphones & Mobile Devices,ACM, 2014, pp. 39–50.

[42] K. Mao, M. Harman e Y. Jia, “Sapienz: Multi-objective automated testingfor Android applications”, em Proceedings of the 25th International Sympo-sium on Software Testing and Analysis, ACM, 2016, pp. 94–105.

[43] M. Xia, L. Gong, Y. Lyu, Z. Qi e X. Liu, “Effective real-time android appli-cation auditing”, em 2015 IEEE Symposium on Security and Privacy, IEEE,2015, pp. 899–914.

BIBLIOGRAFIA 40

BIBLIOGRAFIA

[44] G. Suarez-Tangil, M. Conti, J. E. Tapiador e P. Peris-Lopez, “Detectingtargeted smartphone malware with behavior-triggering stochastic models”,em European symposium on research in computer security, Springer, 2014,pp. 183–201.

[45] H. Tang, G. Wu, J. Wei e H. Zhong, “Generating test cases to expose concur-rency bugs in android applications”, em Proceedings of the 31st IEEE/ACMinternational Conference on Automated software engineering, ACM, 2016,pp. 648–653.

[46] I. C. Morgado e A. C. Paiva, “The impact tool: Testing ui patterns onmobile applications”, em 2015 30th IEEE/ACM International Conferenceon Automated Software Engineering (ASE), IEEE, 2015, pp. 876–881.

[47] Y.-M. Baek e D.-H. Bae, “Automated model-based Android GUI testingusing multi-level GUI comparison criteria”, em Proceedings of the 31st IEE-E/ACM International Conference on Automated Software Engineering, ACM,2016, pp. 238–249.

[48] B. Hassanshahi, Y. Jia, R. H. Yap, P. Saxena e Z. Liang, “Web-to-applicationinjection attacks on android: Characterization and detection”, em EuropeanSymposium on Research in Computer Security, Springer, 2015, pp. 577–598.

[49] R. Sasnauskas e J. Regehr, “Intent fuzzer: crafting intents of death”, emProceedings of the 2014 Joint International Workshop on Dynamic Analysis(WODA) and Software and System Performance Testing, Debugging, andAnalytics (PERTEA), ACM, 2014, pp. 1–5.

[50] Y. Kang, Y. Zhou, H. Xu e M. R. Lyu, “DiagDroid: Android performancediagnosis via anatomizing asynchronous executions”, em Proceedings of the2016 24th ACM SIGSOFT International Symposium on Foundations of Soft-ware Engineering, ACM, 2016, pp. 410–421.

[51] I. C. Morgado e A. C. Paiva, “Testing approach for mobile applications th-rough reverse engineering of UI patterns”, em 2015 30th IEEE/ACM Inter-national Conference on Automated Software Engineering Workshop (ASEW),IEEE, 2015, pp. 42–49.

[52] Z. Qin, Y. Tang, E. Novak e Q. Li, “Mobiplay: A remote execution basedrecord-and-replay tool for mobile applications”, em Proceedings of the 38thInternational Conference on Software Engineering, ACM, 2016, pp. 571–582.

[53] L. Deng, N. Mirzaei, P. Ammann e J. Offutt, “Towards mutation analysisof android apps”, em 2015 IEEE Eighth International Conference on Soft-ware Testing, Verification and Validation Workshops (ICSTW), IEEE, 2015,pp. 1–10.

41 BIBLIOGRAFIA

BIBLIOGRAFIA

[54] L. Gomez, I. Neamtiu, T. Azim e T. Millstein, “Reran: Timing-and touch-sensitive record and replay for android”, em Proceedings of the 2013 Inter-national Conference on Software Engineering, IEEE Press, 2013, pp. 72–81.

[55] M. Gomez, R. Rouvoy, B. Adams e L. Seinturier, “Reproducing context-sensitive crashes of mobile apps using crowdsourced monitoring”, em 2016IEEE/ACM International Conference on Mobile Software Engineering andSystems (MOBILESoft), IEEE, 2016, pp. 88–99.

[56] A. R. Espada, M. del Mar Gallardo, A. Salmeron e P. Merino, “Runtime veri-fication of expected energy consumption in smartphones”, em InternationalSPIN Workshop on Model Checking of Software, Springer, 2015, pp. 132–149.

[57] Q. Sun, L. Xu, L. Chen e W. Zhang, “Replaying harmful data races in An-droid apps”, em 2016 IEEE International Symposium on Software ReliabilityEngineering Workshops (ISSREW), IEEE, 2016, pp. 160–166.

[58] P. Zhang e S. Elbaum, “Amplifying tests to validate exception handling code:An extended study in the mobile application domain”, ACM Transactionson Software Engineering and Methodology (TOSEM), v. 23, n. 4, p. 32, 2014.

[59] Y. L. Arnatovich, M. N. Ngo, T. H. B. Kuan e C. Soh, “Achieving high codecoverage in Android UI testing via automated widget exercising”, em 201623rd Asia-Pacific Software Engineering Conference (APSEC), IEEE, 2016,pp. 193–200.

[60] R. N. Zaeem, M. R. Prasad e S. Khurshid, “Automated generation of oraclesfor testing user-interaction features of mobile apps”, em 2014 IEEE SeventhInternational Conference on Software Testing, Verification and Validation,IEEE, 2014, pp. 183–192.

[61] X. Wu, Y. Jiang, C. Xu, C. Cao, X. Ma e J. Lu, “Testing Android appsvia guided gesture event generation”, em 2016 23rd Asia-Pacific SoftwareEngineering Conference (APSEC), IEEE, 2016, pp. 201–208.

[62] C. C. Yeh, H. L. Lu, C. Y. Chen, K. K. Khor e S. K. Huang, “Craxdroid:Automatic android system testing by selective symbolic execution”, em 2014IEEE Eighth International Conference on Software Security and Reliability-Companion, IEEE, 2014, pp. 140–148.

[63] H. Zhang, H. Wu e A. Rountev, “Automated test generation for detectionof leaks in Android applications”, em Proceedings of the 11th InternationalWorkshop on Automation of Software Test, ACM, 2016, pp. 64–70.

BIBLIOGRAFIA 42

BIBLIOGRAFIA

[64] K. Yang, J. Zhuge, Y. Wang, L. Zhou e H. Duan, “IntentFuzzer: detectingcapability leaks of android applications”, em Proceedings of the 9th ACMsymposium on Information, computer and communications security, ACM,2014, pp. 531–536.

[65] R. Jabbarvand, A. Sadeghi, H. Bagheri e S. Malek, “Energy-aware test-suiteminimization for android apps”, em Proceedings of the 25th InternationalSymposium on Software Testing and Analysis, ACM, 2016, pp. 425–436.

[66] S. Vilkomir e B. Amstutz, “Using combinatorial approaches for testing mo-bile applications”, em 2014 IEEE Seventh International Conference on Soft-ware Testing, Verification and Validation Workshops, IEEE, 2014, pp. 78–83.

[67] Y.-D. Lin, E. T.-H. Chu, S.-C. Yu e Y.-C. Lai, “Improving the accuracy ofautomated GUI testing for embedded systems”, IEEE software, v. 31, n. 1,pp. 39–45, 2013.

[68] J. Qian e D. Zhou, “Prioritizing test cases for memory leaks in android appli-cations”, Journal of Computer Science and Technology, v. 31, n. 5, pp. 869–882, 2016.

[69] H. Shahriar, S. North e E. Mawangi, “Testing of memory leak in android ap-plications”, em 2014 IEEE 15th International Symposium on High-AssuranceSystems Engineering, IEEE, 2014, pp. 176–183.

[70] W. Choi, G. Necula e K. Sen, “Guided gui testing of android apps withminimal restart and approximate learning”, em Acm Sigplan Notices, ACM,vol. 48, 2013, pp. 623–640.

[71] M. Ermuth e M. Pradel, “Monkey see, monkey do: effective generation of GUItests with inferred macro events”, em Proceedings of the 25th InternationalSymposium on Software Testing and Analysis, ACM, 2016, pp. 82–93.

[72] S. Salva e S. R. Zafimiharisoa, “APSET, an Android aPplication SEcurityTesting tool for detecting intent-based vulnerabilities”, International Journalon Software Tools for Technology Transfer, v. 17, n. 2, pp. 201–221, 2015.

[73] T. Azim e I. Neamtiu, “Targeted and depth-first exploration for systema-tic testing of android apps”, em Acm Sigplan Notices, ACM, vol. 48, 2013,pp. 641–660.

[74] H. Zhu, X. Ye, X. Zhang e K. Shen, “A context-aware approach for dynamicgui testing of android applications”, em 2015 IEEE 39th Annual ComputerSoftware and Applications Conference, IEEE, vol. 2, 2015, pp. 248–253.

[75] P. Maiya, A. Kanade e R. Majumdar, “Race detection for Android applica-tions”, em ACM SIGPLAN Notices, ACM, vol. 49, 2014, pp. 316–325.

43 BIBLIOGRAFIA

BIBLIOGRAFIA

[76] T. Zhang, J. Gao, O.-E.-K. Aktouf e T. Uehara, “Test Model and CoverageAnalysis for Location-based Mobile Services.”, em SEKE, 2015, pp. 80–86.

[77] R. Mahmood, N. Mirzaei e S. Malek, “Evodroid: Segmented evolutionarytesting of android apps”, em Proceedings of the 22nd ACM SIGSOFT Inter-national Symposium on Foundations of Software Engineering, ACM, 2014,pp. 599–609.

[78] T. Zhang, J. Gao, J. Cheng e T. Uehara, “Compatibility testing service formobile applications”, em 2015 IEEE Symposium on Service-Oriented SystemEngineering, IEEE, 2015, pp. 179–186.

[79] Y.-D. Lin, J. F. Rojas, E. T.-H. Chu e Y.-C. Lai, “On the accuracy, effici-ency, and reusability of automated test oracles for android devices”, IEEETransactions on Software Engineering, v. 40, n. 10, pp. 957–970, 2014.

[80] M. Wan, Y. Jin, D. Li, J. Gui, S. Mahajan e W. G. Halfond, “Detectingdisplay energy hotspots in Android apps”, Software Testing, Verificationand Reliability, v. 27, n. 6, e1635, 2017.

[81] C.-J. M. Liang, N. D. Lane, N. Brouwers, L. Zhang, B. F. Karlsson, H. Liu,Y. Liu, J. Tang, X. Shan, R. Chandra et al., “Caiipa: Automated large-scalemobile app testing through contextual fuzzing”, em Proceedings of the 20thannual international conference on Mobile computing and networking, ACM,2014, pp. 519–530.

[82] K. Song, A.-R. Han, S. Jeong e S. D. Cha, “Generating various contexts frompermissions for testing Android applications.”, em SEKE, 2015, pp. 87–92.

[83] X. Li, Y. Jiang, Y. Liu, C. Xu, X. Ma e J. Lu, “User guided automationfor testing mobile apps”, em 2014 21st Asia-Pacific Software EngineeringConference, IEEE, vol. 1, 2014, pp. 27–34.

[84] N. Mirzaei, S. Malek, C. S. Pasareanu, N. Esfahani e R. Mahmood, “Tes-ting android apps through symbolic execution”, ACM SIGSOFT SoftwareEngineering Notes, v. 37, n. 6, pp. 1–5, 2012.

[85] A. K. Maji, F. A. Arshad, S. Bagchi e J. S. Rellermeyer, “An empiricalstudy of the robustness of inter-component communication in Android”, emIEEE/IFIP International Conference on Dependable Systems and Networks(DSN 2012), IEEE, 2012, pp. 1–12.

[86] T. Takala, M. Katara e J. Harty, “Experiences of system-level model-basedGUI testing of an Android application”, em 2011 Fourth IEEE InternationalConference on Software Testing, Verification and Validation, IEEE, 2011,pp. 377–386.

BIBLIOGRAFIA 44

BIBLIOGRAFIA

[87] D. Amalfitano, A. R. Fasolino e P. Tramontana, “A gui crawling-based tech-nique for android mobile application testing”, em 2011 IEEE fourth interna-tional conference on software testing, verification and validation workshops,IEEE, 2011, pp. 252–261.

[88] H. Zheng, D. Li, B. Liang, X. Zeng, W. Zheng, Y. Deng, W. Lam, W. Yang eT. Xie, “Automated test input generation for android: Towards getting therein an industrial case”, em 2017 IEEE/ACM 39th International Conferenceon Software Engineering: Software Engineering in Practice Track (ICSE-SEIP), IEEE, 2017, pp. 253–262.

[89] V. Riccio, D. Amalfitano e A. R. Fasolino, “Is this the lifecycle we reallywant?: an automated black-box testing approach for Android activities”,em Companion Proceedings for the ISSTA/ECOOP 2018 Workshops, ACM,2018, pp. 68–77.

[90] Y. Cao, G. Wu, W. Chen e J. Wei, “CrawlDroid: Effective Model-basedGUI Testing of Android Apps”, em Proceedings of the Tenth Asia-PacificSymposium on Internetware, ACM, 2018, p. 19.

[91] S. Yang, D. Yan, H. Wu, Y. Wang e A. Rountev, “Static control-flow analysisof user-driven callbacks in Android applications”, em 2015 IEEE/ACM 37thIEEE International Conference on Software Engineering, IEEE, vol. 1, 2015,pp. 89–99.

[92] W. Choi, K. Sen, G. Necula e W. Wang, “DetReduce: minimizing AndroidGUI test suites for regression testing”, em Proceedings of the 40th Interna-tional Conference on Software Engineering, ACM, 2018, pp. 445–455.

[93] D. Adamo, D. Nurmuradov, S. Piparia e R. Bryce, “Combinatorial-basedevent sequence testing of Android applications”, Information and SoftwareTechnology, v. 99, pp. 98–117, 2018.

[94] J. Yan, L. Pan, Y. Li, J. Yan e J. Zhang, “LAND: a user-friendly and custo-mizable test generation tool for Android apps”, em Proceedings of the 27thACM SIGSOFT International Symposium on Software Testing and Analysis,ACM, 2018, pp. 360–363.

[95] S. Kapoor, K. Sagar e B. Reddy, “Speedroid: A Novel Automation TestingTool for Mobile Apps”, em International Conference on Innovative Compu-ting and Communications, Springer, 2019, pp. 271–285.

[96] I.-A. Salihu, R. Ibrahim, B. S. Ahmed, K. Z. Zamli e A. Usman, “AMOGA: AStatic-Dynamic Model Generation Strategy for Mobile Apps Testing”, IEEEAccess, v. 7, pp. 17 158–17 173, 2019.

45 BIBLIOGRAFIA

BIBLIOGRAFIA

[97] K. Moran, M. Linares-Vasquez, C. Bernal-Cardenas, C. Vendome e D. Poshy-vanyk, “Crashscope: A practical tool for automated testing of android appli-cations”, em 2017 IEEE/ACM 39th International Conference on SoftwareEngineering Companion (ICSE-C), IEEE, 2017, pp. 15–18.

[98] A. B. Bondi, “Characteristics of Scalability and Their Impact on Perfor-mance”, em Proceedings of the 2Nd International Workshop on Softwareand Performance, ser. WOSP ’00, Ottawa, Ontario, Canada: ACM, 2000,pp. 195–203, isbn: 1-58113-195-X. doi: 10.1145/350391.350432. endereco:http://doi.acm.org/10.1145/350391.350432.

BIBLIOGRAFIA 46