Automating GUI Testing for Android Applications Hu - Neamtiu (2011)

Testing for Poor Responsiveness in Android Applications Yang - Yan - Rountev (2013)

Mart´ın Browarnik Alejandro Grinberg Mart´ın Rinemberg

May 31, 2014

Introducci´on

El gran y r´apido crecimiento de las aplicaciones Android en los u ´ltimos a˜ nos, junto a las limitaciones f´ısicas de los dispositivos (en cuanto a CPU, memoria, pantalla, etc.) y sumado al desconocimiento de los desarrolladores de las plataformas m´ oviles y sus herramientas, deriv´o en nuevos errores. Estos no est´aban contemplados en los m´etodos tradicionales de testing, por lo que fue necesario la investigaci´on y el desarrollo de nuevas formas de hacer testing.

Automating GUI Testing for Android Applications En este paper se presenta un enfoque para automatizar el testing. Como objeto de estudio, se tomaron 10 aplicaciones open-source populares para la ´epoca. Los autores proponen una categorizaci´ on de los tipos de bugs y toman los reportes de errores de Google Code de dichas aplicaciones para armar la siguiente tabla.

Android applications: study time frame, bug categories and bug counts.

Categorias de errores

En esta oportunidad se trabaj´ o sobre las siguientes categorias de errores, que son aquellas que los autores consideran como GUI bugs: Activities: ocurren generalmente por implementaciones incorrectas del protocolo de activities. Las activities son componentes principales de la GUI de cualquier aplicaci´ on Android y su ciclo de vida esta descripto por una maquina de estados. Cualquier violaci´on de la misma, deriva en un activity bug. Events: ocurren cuando la app realiza una acci´ on incorrecta como resultado de recibir un evento. Dynamic type: surgen de excepciones de tipo en tiempo de ejecuci´on.

T´ecnica propuesta El enfoque consiste en los siguientes pasos 1 Generaci´ on autom´atica de casos de test usando JUnit 2 Generaci´ on autom´atica de secuencias de eventos usando Monkey 3 Generaci´ on de logs de las ejecuciones de los casos de test 4 An´ alisis de logs y detecci´ on de bugs

Overview of our approach.

Detecci´on de bugs Teniendo los logs, para cada clase de errores se utilizan ciertos patrones para identificar potenciales bugs. Activity bugs: se utiliza la m´aquina de estados como una especificaci´on contra la que se matchean las llamadas a m´etodos logueadas. Violaciones a esta especificaci´on son marcadas como bugs potenciales.

Simplified state machine of an Android activity.

Event bugs: las aplicaciones deber´ıan estar preparadas para recibir eventos y reaccionar frente a ellos en cualquier estado de cualquier actividad. Si al realizar un evento, este no fue controlado puede pasar a un estado incorrecto o producir un crash, lo que se puede identificar en el log. Type errors: una vez que se desat´ o el error, una entrada de classCastException aparece en el log.

Bug manifestation: examples of log file entries for each bug category.

Resultados Se encontraron todos los bugs ya reportados salvo 3 de tipo event que tampoco pudieron reproducirse por otros usuarios (manualmente). Se encontraron 3 activity bugs nuevos y 6 event bugs nuevos. No se encontraron nuevos errores de tipo Dynamic type, probablemente a causa de que su criticidad hace que sean facilmente observables, reportados y corregidos.

Results: old (re-discovered) bugs and new (not previously reported) bugs.

Testing for Poor Responsiveness in Android Applications En este paper se propone una t´ecnica sistem´atica para descubrir y cuantificar causas comunes de poor responsiveness en aplicaciones Android. Si una app tarda m´as de 200ms en responder a un evento, se percibe como lenta y unresponsibe. El peor escenario es el ANR (Android Not Responding) error, lanzado por Android cuando considera que la aplicaci´on dej´ o de responder (5s luego de recibir un evento). Poor responsiveness puede ser muy da˜ nino para la aplicaci´on, pudiendo llegar a producir una mala percepci´ on de la misma en general. Esto puede terminar en que los usuarios desinstalen o dejen de usar la misma y en el peor de los casos, poniendo un mal rating y un comentario negativo en el Play Store.

Test amplification El thread principal de una aplicaci´ on Android es el UI thread (el que procesa los eventos UI) y por ende no deber´ıa realizar c´alculos pesados, uso inapropiado de recursos u operaciones de larga espera. A estas operaciones costosas se las conoce como jank. Muchos problemas relacionados con poor responsiveness no se detectan en la etapa de desarrollo. Por ejemplo, al utilizar emuladores, el acceso a red es tipicamente m´as r´apido y por ende no surgen problemas, que en una red 3G si suceden. La propuesta consiste en ejecutar casos de prueba para cubrir cada estado y transici´on del grafo GUI de la aplicaci´ on, y luego re-ejecutarlos en un ambiente modificado en donde se insertan largos delays artificiales en fuentes t´ıpicas de jank. A esto se lo conoce como test amplification.

Modelo GUI El testing se realiza basado en el modelo GUI. Este es un grafo dirigido donde los nodos son estados GUI (Activities) y las aristas son las transiciones disparadas por los eventos GUI. El m´ odelo se puede obtener a partir de la documentaci´on o realizando ingenier´ıa reversa. Los autores utilizaron la herramienta AndroidRipper para construir el modelo GUI de las aplicaciones de su caso de estudio.

Subset of the GUI model for APV (PDF viewer application).

T´ecnica propuesta Se genera un conjunto de casos de test basados en el modelo que cubre cada estado y cada transici´ on y se implementan en Robotium. Se ejecuta luego el test de amplificaci´ on, midiendo el tiempo de respuesta original y los tiempos de respuesta luego de agregar los delays. Los cambios en los tiempos de respuesta se pueden ver como una funci´on respecto a la duraci´on de los delays insertados. Esto provee una caracterizaci´on de los efectos de estas llamadas a janks en el usuario. La implementaci´on de la amplificaci´ on usa AspectJ para instrumentar la aplicaci´on. Se agrega c´odigo de instrumentaci´ on inmediatamente antes de cada API call de las descriptas a continuaci´ on. Durante la ejecuci´on, se introduce un delay configurable. El tiempo de respuesta se usa para medir el efecto sobre responsiveness.

Categor´ıas de jank Se hace foco en las siguientes 4 categor´ıas que representan las fuentes m´as comunes de jank: Acceso a la red: en los experimentos se consideraron 15 m´etodos API de acceso a la red. Acceso a memorias flash: es recomendable evitar incluso operaciones simples de disco en el UI thread. Se consideraron 25 m´etodos. Acceso a BD: el acceso a una BD puede generar una cantidad sustancial de escrituras costosas a la memoria flash. Se consideraron 11 m´etodos Procesamiento de mapa de bits: esto puede ser computacionalmente costoso. Se amplifican llamadas a 6 m´etodos para simular que una imagen HD grande se carga de disco y se decodifica.

Resultados Los experimentos se hicieron sobre 8 aplicaciones Android open source. Los resultados demostraron que las 8 aplicaciones tuvieron alguna operaci´on janky en el UI thread. Los desarrolladores parecen haber tenido cuidad con las operaciones de acceso a red (s´ olo hay un ANR de este tipo). Esto puede explicarse teniendo en cuenta que es conocido que estas operaciones son sensibles a responsiveness. Las otras categorias tienen m´as fallos, siendo acceso a BD la mayor.

Experimental results.

Casos de estudio

Se presentan 4 casos de estudio basados en las pruebas con resultados fallidos, con el objetivo de ver como prevenir los problemas hallados: Connectbot (cliente SSH): cuando el usuario presiona una tecla, esta se env´ıa encriptada sobre la red. Dependiendo de la congesti´on de la misma y del estado de la m´aquina remota, un write socket puede bloquear el UI thread por varios segundos, generando un ANR. Se recomienda utilizar un thread separado para el env´ıo. K-9 (cliente mail): cuando el usuario descarga un adjunto al file system local, los archivos se escriben en la memoria flash dentro del UI thread. Ser´ıa recomendable usar una asyncTask.

Casos de estudio (cont.)

VLC (reproductor multimedia): antes de reproducir cualquier archivo de audio, VLC utiliza el UI thread para cargar la imagen de portada del disco (que en la mayor´ıa de los casos se encuentra en la memoria flash). Decodificar esta imagen desde all´ı a un objeto bitmap grande puede resultar en poor responsiveness. M´as a´ un, la misma imagen puede ser decodificada multiples veces si el usuario cambia de archivo y vuelve al primero. Astrid (agenda/asistente): en varias ocasiones, se encontraron operaciones a la BD SQLite dentro del UI thread. Se recomienda usar los mecanismos provistos por Android como handlers, asyncTasks e intentServices.

¿Preguntas?