Testing Apps Móviles

Bloque B.
Sistemas Ubicuos
Tema 4.
FIABILIDAD Y ROBUSTEZ
Sistemas Empotrados y Ubicuos
Máster Universitario en Ingeniería Informática
Tabla de contenidos
Introducción
Matriz de pruebas
Importancia de las pruebas
App nativas vs. App web
Caso de estudio: Testing y debug en Android

Nos encontramos con…
Distintos dispositivos.
Distintas funcionalidades de usuario.
Accesibilidad y operatividad en distintas localizaciones.
Cambios en el modo de conexión con servidores (Activo-Pasivo).
Todo ello incluyendo combinaciones de:
◦ Móviles.
◦ Conectividad: bluetooth, wifi, 3G, 4G, 5G, etc.
◦ Servidores y red subyacentes.

Modelos de ejecución
En un dispositivo en modo stand-alone * Dependiendo de si los
datos están sólo en local
◦ Dependiente sólo del hardware
◦ Ej: juegos, calendarios y agendas*, juegos*, libreta de direcciones*, etc.
Remotamente en un servidor:
◦ El dispositivo visualiza los resultados y permite interactuar
◦ Ej: Mobile TV, email, redes sociales, etc.

Problemas que plantea:
La aplicación funciona en una plataforma (S.O)
◦ Pero NO para todos los dispositivos del mismo fabricante.
Las aplicaciones se desarrollan rápidamente
◦ Pero sin pruebas software
◦ Sólo centrados en la funcionalidad, no en la robustez...
◦ En algunos casos, probadas sobre emuladores
◦ NO sobre dispositivos físicos... NO es suficiente
◦¡PROBLEMA A RESOLVER!
¿Preguntas a realizar?
¿Con qué dispositivos y versiones de S.O funcionará esta aplicación?
¿Cómo realizamos pruebas para asegurar que funcionan en esas plataformas?
¿Cambios necesarios para ajustar las diferencias entre plataformas?
¿Cómo se adecúa el proceso de desarrollo y testing a las diferencias entre
protocolos wireless y servicios móviles?
¿Cuánto debemos probar?
Etc.

Los problemas añadidos..
Diversidad del hardware muy grande y cambiante en el tiempo
Complejidad sofware:
◦ Variantes de S.O más grande y con cambio continuo.
◦ La posición dominante de un S.O puede cambia en mucho menos tiempo que en el mundo de
los PC (recordemos el caso de estudio en temas anteriores, como S.O. Symbian…)
Diversidad de redes.
No disponibilidad de N dispositivos físicos para testing (costes).
◦ Obligando a usar emuladores...

Mapa conceptual de testing apps
móviles (complejidad excesiva)
Estáis preparados.

Simplificando...
Niveles de pruebas Técnicas de pruebas
Pruebas en
Aplicaciones Móviles
Alcance de las pruebas Entorno de pruebas

Niveles de Pruebas
Niveles "clásicos" equivalentes en otros contextos de pruebas
◦ Con algunas sutiles diferencias..

Técnicas de Pruebas

Ámbito de las Pruebas
Nuevos ámbitos no contemplados en otros software o bien que toman un papel mucho más
importante.

Entorno de Pruebas
Dispositivo físico vs. Emulador

App’s
Nativas VS. WEB
Nativas WEB
• El testeo comienza con la instalación y • Sin instalación.
ejecución de la aplicación • El renderizado depende del navegador
• Puede requerir acceso especial al • iOS con Safari
dispositivo • Android propietario también con Chrome,
Dolphin, Opera Mini, Firefox, etc.
• La funcionalidad y usabilidad debe
• Windows Mobile con Edge
probarse en varios dispositivos: • Blackberry con nativo, Opera Mini o Bolt
• S.O y versión • Requiere conexión a internet
• Tamaño de pantalla • La conectividad varía...
• Interrupciones • Tiempo de carga:
• Acceso a APIs adicionales. • 60% de usuarios esperan tiempos < 3 seg.

Testing y debug en
Android
CASO DE ESTUDIO
Test Android Framework
Android proporciona una arquitectura y herramientas para ayudar a probar cada
aspecto de una aplicación en todos sus niveles.
• La suite de test esta basado en Junit (JUnit 4)
• Android extiende JUnit para proporcionar componentes específicos
• Los paquetes de test específicos de Android son similares a los paquetes de aplicación.
• Ejecución como tests locales en la MVJ
• Como tests instrumentados sobre un dispositivo Android
• Por último el SDK proporciona entornos de ejecución “monkey”

Un test de Junit es un método cuyos estados prueban partes de una aplicación.
Los métodos del test se organizan en unas clases llamada casos de test o Suite
Cada test debe estar aislado del resto en un modulo de la aplicación que se va
a probar.
Generalmente las clases de test suelen tener solo métodos de test pero
también pueden tener métodos de ayuda.
En JUnit se usa una test-runner para correr las clases de test
En Android se usa las herramientas de test para cargar los paquetes de test y la
aplicación a testear y la herramienta corre un test-runner específico para
Android

Los test se organizan dentro del proyecto de Android Studio:
 module-name/src/test/java/
 Se ejecutan en local sin acceso a la API del framework Android (necesita de Mocks…)
 module-name/src/androidTest/java/
 Test instrumentados a ejecutar sobre dispositivo o emulador
 Empaquetados como apk
 Con dependencias que NO se pueden “mockear”
[Fuente: Android.com, 2018]

Test Android Framework: Integración
 Pruebas de integración
Interacción con la UI (intra-app)
 Ej: Espresso
Integración con otras apps (externa)
 Ej: UI Automator

AndroidJUnitRunner: ejecutor de pruebas compatibles con JUnit 3 y 4 para
Android.
Incluidas aquellas que usan los frameworks de pruebas Espresso e UI
Automator.
Reemplaza la clase InstrumentationTestRunner, que solo admitía las pruebas
JUnit 3.
Evitar la combinación de test Junit 3 y 4
Se utiliza la anotación: @RunWith(AndroidJUnit4.class)

Anotaciones especiales:
Anotación Funcionalidad
@RequiresDevice Requiere ejecutarse en dispositivo físico
@SdkSupress Impide que la prueba se ejecute en un nivel de Android API inferior al nivel en
cuestión (ej: @SDKSupress(minSdkVersion=18))
@SmallTest, clasifica el tiempo que lleva la ejecución de una prueba y, posteriormente, la
@MediumTest frecuencia con la que puedes ejecutarla
@LargeTest

API de instrumentación básica
Runner
Ejemplo: @RunWith(AndroidJUnit4.class)
public class CalculatorInstrumentationTest
extends ActivityInstrumentationTestCase2<CalculatorActivity> {
@Before
public void setUp() throws Exception {
super.setUp();
Testing de actividades
// Inyección requerida para testar con AndroidJUnitRunner.

injectInstrumentation(InstrumentationRegistry.getInstrumentation());
mActivity = getActivity();
}
@Test Dependencias de instrumentación.

public void typeOperandsAndPerformAddOperation() { NO se puede ejecutar en la MVJ
local
// Llama a métodos de CalculatorActivity
// comprueba que los valores obtenidos son los esperados.
}
@After
public void tearDown() throws Exception {
super.tearDown();
}
}

Stub
Stub es un trozo de código usado como sustituto de alguna otra funcionalidad.
El test driver simula las partes del programa que invocan a la unidad testada.
El stub simulan las partes del programa llamadas por la unidad testada.
Deben:
 Chequear el entorno provisto por el invocador
 Chequear los argumentos del invocador
 Modificar los argumentos y entorno devolviendo valores con los que el invocador pueda trabajar, intentando cubrir la
especificación del módulo que el stub está simulando (no siempre es posible)
Se comprueban los estados intermedios.
Stub
Test Driver Módulo
Stub

Moks
Objetos simulados que imitan el comportamiento de objetos reales
de una forma controlada.
Función "similar" a los stubs.
Se comprueban además las interacciones entre los módulos.

Stub vs. Mocks
Los Stubs proporcionan respuestas prefedinidas a ciertas llamadas durante los
tests, sin responder a cualquier otra cosa para la que no hayan sido
programados.
Los Mocks son objetos pre-programados con expectativas que conforman la
especificación de lo que se espera que reciban las llamadas.
Los Mocks se utilizan para verificar el comportamiento de un elemento y los stubs
para verificar el estado.

Stub y Moks
Soluciones:
◦ Implementación manual del stub o mock (desaconsejada)
◦ Bibliotecas y frameworks de terceros, construidas sobre la base de JUnit:
◦ Mockito http://code.google.com/p/mockito/
Android provee sus propios

◦ PowerMock http://code.google.com/p/powermock/ MockObjects
◦ jMock http://www.jmock.org/
◦ EasyMock http://easymock.org/
◦ JMockIt http://code.google.com/p/jmockit/
Hay otras alternativas para Mocks en
◦ Etc Java pero no han sido adoptadas por
Android
Configuración de testing con Mocks
(Mockito)
 En test locales con dependencias menores de Android
 Configuración en build.gradle:
dependencies {
// Required -- JUnit 4 framework
testCompile 'junit:junit:4.12'
// Optional -- Mockito framework
testCompile 'org.mockito:mockito-core:1.10.19'
}
 Si se intentan ejecutar métodos de Android directamente genera excepciones

 Se puede cambiar este comportamiento, para que devuelvan valores por defecto (null, false, 0, etc.) pero es peligroso…
android {
...
testOptions {
unitTests.returnDefaultValues = true
}
 Es necesario usar los mocks y mockear los métodos Android: }
 Mockito (version 1.9.5 o superior) ofrece compatibilidad con los tests Android
 En versiones previas se incluían mocks particulares de Android

Configuración de testing con Mocks
(Mockito)
Runner para Mockito
Ejemplo: @RunWith(MockitoJUnitRunner.class)
public class UnitTestSample {
Objeto “mockeado” private static final String FAKE_STRING = "HELLO WORLD";
@Mock
Context mMockContext;
@Test
public void readStringFromContext_LocalizedString() {
// Da un contexto inyectado “mockeado” al objeto a probar...
when(mMockContext.getString(R.string.hello_word))
.thenReturn(FAKE_STRING);
ClassUnderTest myObjectUnderTest = new ClassUnderTest(mMockContext);
// ...cuando el objeto testado devuelve un String...

String result = myObjectUnderTest.getHelloWorldString();
// ... El resultado debería ser el esperado.

assertThat(result, is(FAKE_STRING));
}
}

Test Instrumentados
 Configuración en build.gradle:
dependencies {
androidTestCompile 'com.android.support:support-annotations:24.0.0'
androidTestCompile 'com.android.support.test:runner:0.5'
androidTestCompile 'com.android.support.test:rules:0.5'
// Optional -- Hamcrest library
androidTestCompile 'org.hamcrest:hamcrest-library:1.3'
// Optional -- UI testing with Espresso
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.2'
// Optional -- UI testing with UI Automator
androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.2'
}
Para ejecutar test JUnit 4 añadir: android {

defaultConfig {
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
}

Test Instrumentados
@SmallTest Runner
public class LogHistoryAndroidUnitTest {
public static final String TEST_STRING = "This is a string";

public static final long TEST_LONG = 12345678L;
private LogHistory mLogHistory;
OUT (Object Under
@Before Test) – comprobar que
public void createLogHistory() { implementa la interfaz
mLogHistory = new LogHistory(); Parcelable
}
correctamente
@Test
public void logHistory_ParcelableWriteRead() {
Clase Android // Configura el objeto Parcelable para enviar y recibir.
NO MOCK mLogHistory.addEntry(TEST_STRING, TEST_LONG);
// Escribir datos
Parcel parcel = Parcel.obtain();
mLogHistory.writeToParcel(parcel, mLogHistory.describeContents());
// Después de escribir, se resetea para lectura.

parcel.setDataPosition(0);
// Leer datos
LogHistory createdFromParcel = LogHistory.CREATOR.createFromParcel(parcel);
List<Pair<String, Long>> createdFromParcelData = createdFromParcel.getData();
// Verificar que los datos recibidos son correctos.

assertThat(createdFromParcelData.size(), is(1));
assertThat(createdFromParcelData.get(0).first, is(TEST_STRING));
assertThat(createdFromParcelData.get(0).second, is(TEST_LONG));
}
}

Test Instrumentados
de test instrumentados sobre distintos dispositivos con
 Ejecución
Firebase Lab
 https://firebase.google.com/
 Necesita cuenta Google

 Sin costes pero con funcionalidad limitada:
 Más detalles en: https://developer.android.com/training/testing/unit-testing/instrumented-unit-
tests.html
 Otras plataformas similares: BitBar (antes TestDroid) en http://bitbar.com/testing/

Espresso
Reemplaza a lo visto anteriormente para testing de UI.
Parte de Android Support Testing Library
https://google.github.io/android-testing-support-library/
Parte de Android (y de sus repositorios)

Espresso
@LargeTest
public class MainActivityInstrumentationTest {
Evita heredar de
ActivityInstrumentationTestCase2 @Rule
public ActivityTestRule mActivityRule = new ActivityTestRule<>(
MainActivity.class);
@Test
public void sayHello(){
onView(withText("Say hello!")).perform(click());
onView(withId(R.id.textView)).check(matches(withText("Hello, World!")));
}
}

Espresso
 Nota: asume que se usa el
patrón Model-Presenter-
View en el desarrollo
Cheat sheet disponible en

https://developer.android
.com/training/testing/esp
resso/cheat-sheet

Espresso
 Generación de tests con “grabadoras” (ej: tipo Selenium)
 Espresso Test Recorder
Integrado en Android Studio
Con ciertas limitaciones (funcionalidad reducida, no disponible todo el conjunto de View
Assertions, etc.)
Personalizable en Android Studio
Buena solución para genera un “esqueleto” inicial aunque luego haya que programar a mano
Más documentación: https://developer.android.com/studio/test/espresso-test-
recorder.html?hl=es-419

Testing de servicios (sin UI)
 Deben ser probados en test instrumentados
@RunWith(AndroidJUnit4.class)
@LargeTest
public class MainServiceInstrumentationTest {
 Regla ServiceTestRule (similar a ActivityTestRule) @Rule
 Inicia y para el servicio en la ejecución de los tests public final ServiceTestRule mServiceRule = new ServiceTestRule();
@Test
Ejemplo: public void testWithBoundService() throws TimeoutException {
// Crea el Intent de servicio
Intent serviceIntent =
new Intent(InstrumentationRegistry.getTargetContext(), LocalService.class);
// Se pueden pasar datos al servicio via Intent

serviceIntent.putExtra(LocalService.SEED_KEY, 42L);
// Vincular el servicio y atrapar referencia al binder.

IBinder binder = mServiceRule.bindService(serviceIntent);
// Obtener referencia al servicio,

// o bien llamar al método público en el binder directamente
LocalService service =
((LocalService.LocalBinder) binder).getService();
// Verificar que el servicio está funcionando correctamente.

assertThat(service.getRandomInt(), is(any(Integer.class)));
}

Testing de proveedores de contenido (sin
UI)
 Deben ser probados en test instrumentados a la “vieja” usanza: heredando de
ProviderTestCase2
 Necesario establecer el contexto con el contexto instrumentado.
Utiliza mocks propios de Android (solución previa) para ejecutar en un entorno “aislado”
@RunWith(AndroidJUnit4.class)
@LargeTest
public class MainProviderInstrumentationTest extends ProviderTestCase2 {
@Override
protected void setUp() throws Exception {
setContext(InstrumentationRegistry.getTargetContext());
super.setUp();
}
...
// añadir tests
}

UI Automator
 Pruebas de IU que realizan interacciones en las apps del usuario y las app del sistema.
 Requiere mínimos de Android 4.3 (nivel de API 18)
 Herramienta uiautomatorviewer proporciona una GUI para escanear y analizar los
componentes de IU que se muestran en un dispositivo Android
 Clase UiDevice para acceder al dispositivo en el cuál se ejecuta una app de destino y realizar
operaciones en él.
 API específica UI Automator

UI Automator
Ejemplo: // Inicializar UiDevice
mDevice = UiDevice.getInstance(getInstrumentation());
// Realizar presión corta en el botón Home

mDevice.pressHome();
// Traer al frente el lanzador por defecto

// buscando un componente que se ajuste
UiObject allAppsButton = mDevice
.findObject(new UiSelector().description("Apps"));
// Realiza un click para ejecutar el lanzador

allAppsButton.clickAndWaitForNewWindow();

Configuración Espresso y UI Automator
 Paquete de bibliotecas de compatibilidad de pruebas de Android descargable con Android SDK
Manager
 Packages / Extras / Android Support Repository
 Configuración en build.gradle: dependencies {

androidTestCompile 'com.android.support.test:runner:0.4'
// Set this dependency to use JUnit 4 rules
androidTestCompile 'com.android.support.test:rules:0.4'
// Set this dependency to build and run Espresso tests
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.1'
// Set this dependency to build and run UI Automator tests
androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.2'
}
 Configuración del ejecutor en build.gradle

android {
defaultConfig {
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
}

Test del “Mono”
Automatizar aleatoriamente eventos
◦ Clasificadas como pruebas de robustez o stress
Parámetros ajustables:
◦ Opciones de configuración: número de eventos, etc.
1. Restricciones. Ej: paquete objetivo
2. Tipo de eventos y frecuencias
3. Opciones de depuración
◦ Si la aplicación: aborta, lanza excepción o no responde se informa

Monkey
 En línea de comandos que envía eventos aleatoriamente
 Se ejecuta con Android Debug Bridge (adb)
 Estresa la aplicación e informa de errores
 Ejemplos:
$ adb shell monkey –help // muestra la ayuda
$ adb shell monkey -p com.lsi.myapp 5000 // ejecuta la app con 5000 eventos
$ adb shell monkey -p com.lsi.myapp -p com.google.map 5000 // ejecuta permitiendo la
apertura de la aplicación de mapas (en caso contrario no “sale” de la app)
$ adb shell monkey --pct-touch 30 -p com.lsi.myapp 5000 // 30% de eventos son toques en
pantalla

# Imports the monkeyrunner modules used by this program
monkeyrunner
from com.android.monkeyrunner import MonkeyRunner, MonkeyDevice
# Connects to the current device, returning a MonkeyDevice object

device = MonkeyRunner.waitForConnection()
# Installs the Android package.

En línea de comandos # Notice that this method returns a boolean, so you can test
# to see if the installation worked.
◦ Entorno de ejecución y API escrita device.installPackage('myproject/bin/MyApplication.apk')
en Python # sets a variable with the package's internal name

package = 'com.example.android.myapplication'
Permite: # sets a variable with the name of an Activity in the package

activity = 'com.example.android.myapplication.MainActivity'
◦ Conexión al dispositivo # sets the name of the component to start
◦ Instalar/desinstalar apks. runComponent = package + '/' + activity
◦ Captura de pantallas y comparación # Runs the component

device.startActivity(component=runComponent)
◦ Ejecución de tests contra la aplicación # Presses the Menu button

device.press('KEYCODE_MENU', MonkeyDevice.DOWN_AND_UP)
# Takes a screenshot
result = device.takeSnapshot()
# Writes the screenshot to a file

result.writeToFile('myproject/shot1.png','png')
Documentación completa: https://developer.android.com/studio/test/monkeyrunner/index.html

Puntos calientes en las pruebas
Cambiar la orientación de la pantalla
◦ ¿Se redibuja "bien"?
◦ ¿Se mantiene el estado?
Cambios en la configuración
◦ Disponibilidad de teclado o cambio de idiomas
◦ ¿Responde adecuadamente a los cambios?
Uso de batería
◦ Ver:
◦ http://www.google.com/intl/es-ES/events/io/2009/sessions/CodingLifeBatteryLife.html
Dependencia de recursos externos

◦ Red, GPS, etc.
◦ ¿Qué ocurre cuando no están disponibles?

Debug
Android Device Monitor
Encapsula un conjunto de herramientas: “Deprectated” en favor
 DDMS de su uso desde
Android Studio a partir
 Tracer for OpenGL ES de la versión 3.0
 Hierarchy Viewer
 Systrace
 Traceview
 Pixel Perfect
Ejecutando en %ANDROID_HOME%/tools/ el commando monitor

Android Studio (3.0 en adelante)
Entorno integrado completo con herramientas “clásicas” de depuración: Ejecutar en
 Seleccionar dispositivo para depurar la app modo
 Establecer puntos de interrupción en el código depuración
 Examinar variables y evaluar expresiones en el tiempo de ejecución.
 Realizar capturas de pantalla y videos de tu app
 Integra a su vez:
 Android Device Monitor
 El antiguo DDMS (Dalvik Debug Monitor Server) de versiones previas
Combinado con vistas en ejecución como:

 LogCat
 Android Profiler

Bibliografía.
[Selvam & Karthikeyani, 2011] Selvam R & V. Karthikeyani. Mobile Software Testing – Automated
Test Case Design Strategies. International Journal on Computer Science and Engineering (IJCSE).
Pages 1450-1461. ISSN : 0975-3397 Vol. 3 No. 4 Apr 2011
[Conder & Darcey, 2011 Conder, S. And Darcey, L. (2011) Android Wireless Application
Development. Addison-Wesley. 2nd Edition ISBN 978-0-321-74301-5

Documentación adicional
● uTest:
● Software Testing.
● http://www.utest.com/
● Android Dev Guide:

● Testing
● https://developer.android.com/training/testing/start/index.html
● Android Device Monitor

● https://developer.android.com/studio/profile/monitor
● Depuración en Android
● https://developer.android.com/studio/debug/

50/
Recursos en GitHub
● Android Testing Samples
● https://github.com/googlesamples/android-testing
● Android Testing Templates

● https://github.com/googlesamples/android-testing-templates

51/
Licencia
Autor: Raúl Marticorena.
Ver 2014 actualizada por Pedro Renedo
Ver 2015 actualizada por Rodrigo Manjón
Ver 2017 y 2018 actualizada por Raúl Marticorena
Área de Lenguajes y Sistemas Informáticos
Departamento de Ingeniería Civil
Escuela Politécnica Superior
UNIVERSIDAD DE BURGOS
Este obra está bajo una licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 4.0 Unported.
No se permite un uso comercial de esta obra ni de las posibles obras derivadas, la distribución de las cuales se debe
hacer con una licencia igual a la que regula esta obra original
Licencia disponible en https://creativecommons.org/licenses/by-nc-sa/4.0/

52/

Testing Apps Móviles

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Testing Apps Móviles

Cargado por

Copyright:

Formatos disponibles

Bloque B.

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

Alcance de las pruebas Entorno de pruebas

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

[Fuente: Android.com, 2018]

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

// Inyección requerida para testar con AndroidJUnitRunner.

@Test Dependencias de instrumentación.

Sistemas Empotrados y Ubicuos

Se comprueban los estados intermedios.

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

Android provee sus propios

 Si se intentan ejecutar métodos de Android directamente genera excepciones

Sistemas Empotrados y Ubicuos

Objeto “mockeado” private static final String FAKE_STRING = "HELLO WORLD";

// ...cuando el objeto testado devuelve un String...

// ... El resultado debería ser el esperado.

Sistemas Empotrados y Ubicuos

Para ejecutar test JUnit 4 añadir: android {

Sistemas Empotrados y Ubicuos

public static final String TEST_STRING = "This is a string";

// Después de escribir, se resetea para lectura.

// Verificar que los datos recibidos son correctos.

Sistemas Empotrados y Ubicuos

 Necesita cuenta Google

 Otras plataformas similares: BitBar (antes TestDroid) en http://bitbar.com/testing/

Sistemas Empotrados y Ubicuos

Parte de Android (y de sus repositorios)

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

Cheat sheet disponible en

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

// Se pueden pasar datos al servicio via Intent

// Vincular el servicio y atrapar referencia al binder.

// Obtener referencia al servicio,

// Verificar que el servicio está funcionando correctamente.

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

Sistemas Empotrados y Ubicuos

// Realizar presión corta en el botón Home

// Traer al frente el lanzador por defecto

// Realiza un click para ejecutar el lanzador

Sistemas Empotrados y Ubicuos

 Configuración en build.gradle: dependencies {

 Configuración del ejecutor en build.gradle