Tutorial de prueba de aplicaciones de Android con Automation Framework

Tabla de contenido:

Anonim

¿Por qué las pruebas de Android?

Android es el sistema operativo más grande del mundo. Al mismo tiempo, Android está fragmentado. hay toneladas de dispositivos y versiones de Android con los que su aplicación debe ser compatible.

No importa cuánto tiempo invierta en el diseño y la implementación, los errores son inevitables y aparecerán errores.

En este tutorial, aprenderá:

  • ¿Por qué las pruebas de Android?
  • Estrategia de prueba de Android
    • Pruebas unitarias
    • Pruebas de integración
    • Pruebas operacionales
    • Pruebas del sistema
  • PRUEBAS DE ANDROID automatizadas
    • Marco de prueba de Android
    • Marco de prueba roboeléctrico
  • Mitos de las pruebas de Android
  • Mejores prácticas en pruebas de Android

Estrategia de prueba de Android

Una estrategia de prueba de Android correcta debe incluir lo siguiente

  1. Prueba de unidad
  2. Examen de integración
  3. Prueba operacional
  4. Prueba del sistema

Pruebas unitarias

Las pruebas unitarias incluyen conjuntos de uno o más programas diseñados para verificar una unidad atómica de código fuente, como un método o una clase.

La plataforma Android viene con el marco Junit 3.0 preintegrado. Es un marco de código abierto para automatizar las pruebas unitarias. Android Testing Framework es una herramienta poderosa para que el desarrollador escriba el programa de prueba de unidad eficaz.

La integración de Android y JUnit framework

Una adición a las pruebas unitarias son las pruebas de interfaz de usuario (UI). Estas pruebas se relacionan con los componentes de la interfaz de usuario de su aplicación de destino. Las pruebas de IU garantizan que su aplicación devuelva la salida de IU correcta en respuesta a la secuencia de acciones del usuario en el dispositivo.

Acciones comunes de la interfaz de usuario del usuario en la aplicación

La forma común de realizar pruebas de IU en el dispositivo es la instrumentación de Android. Pero esto tiene problemas de rendimiento. Una de las mejores herramientas para realizar pruebas de IU en Android es Robotium.

Pruebas de integración

En las pruebas de integración, todos los módulos probados por la unidad se combinan y verifican. En Android, las pruebas de integración a menudo implican verificar la integración con componentes de Android, como pruebas de servicios, pruebas de actividad, pruebas de proveedores de contenido, etc.

Tipos de prueba de integración en Android

Hay muchos marcos de prueba que se utilizan para realizar pruebas de integración para Android, como Troyd, Robolectric, Robotium.

Pruebas operacionales

  • Las pruebas operativas también se denominan pruebas funcionales o pruebas de aceptación. Son pruebas de alto nivel diseñadas para comprobar la integridad y corrección de la aplicación.
  • En Android, FitNesse es un marco de código abierto que facilita la realización de pruebas operativas para la aplicación de destino.

Pruebas del sistema

En System Testing, el sistema se prueba como un todo y se verifica la interacción entre los componentes, el software y el hardware.

En Android, las pruebas del sistema normalmente incluyen

  • Pruebas de GUI
  • Pruebas de usabilidad
  • Pruebas de rendimiento
  • Pruebas de estrés

En la lista anterior, se presta más atención a las pruebas de rendimiento . Puede usar herramientas como Traceview para realizar pruebas de rendimiento en Android. Esta herramienta puede ayudarlo a depurar su aplicación y perfilar su rendimiento.

PRUEBAS DE ANDROID automatizadas

Como Android está fragmentado, es necesario realizar pruebas en multitud de dispositivos. Pero esto también le costará dinero. Las pruebas automatizadas de Android pueden ayudar a reducir costos

Beneficios de las pruebas automatizadas de Android

  • Reducir el tiempo de ejecución de casos de prueba
  • Aumente la productividad de su proceso de desarrollo
  • Detección temprana de errores, ahorre costos en el mantenimiento del software
  • Encontró rápidamente y corrigió los errores en la implementación
  • Asegurar la calidad del software

Estudiaremos los siguientes 2 marcos

  • Marco de prueba de Android
  • Marco de pruebas roboeléctricas

Marco de prueba de Android

Uno de los marcos de prueba estándar para aplicaciones de Android es el marco de prueba de Android . Es un marco de prueba potente y fácil de usar que está bien integrado con las herramientas del SDK de Android.

Arquitectura del marco de pruebas de Android

  1. El paquete de la aplicación es su aplicación de destino que debe probarse
  2. InstrumentationTestRunner es el corredor de casos de prueba que ejecuta el caso de prueba en la aplicación de destino. Incluye:

2a) Herramientas de prueba: herramientas SDK para pruebas de construcción. Están integrados en Eclipse IDE o se ejecutan como línea de comando.

2b) MonkeyRunner: una herramienta que proporciona API para escribir programas que controlan un dispositivo o emulador de Android fuera del código de Android.

  1. Los paquetes de prueba están organizados en proyectos de prueba. Este paquete sigue la convención de nomenclatura. Si la aplicación bajo prueba tiene un nombre de paquete de "com.mydomain.myapp", el paquete de prueba debe ser "com.mydomain.myapp.test". El paquete de prueba incluye 2 objetos como se muestra a continuación:

3a) Clases de casos de prueba: incluyen métodos de prueba para ejecutar en la aplicación de destino.

3b) Objetos simulados: incluye datos simulados que se utilizarán como entrada de muestra para casos de prueba.

Clases de casos de prueba de Android

Diagrama de clases de AndroidTestCase

  1. TestCase incluye métodos JUnit para ejecutar la prueba JUnit
  2. TestSuite se utiliza para ejecutar un conjunto de casos de prueba
  3. InstrumentationTestSuite es un TestSuite que inyecta Instrumentation en InstrumentationTestCase antes de ejecutarlos.
  4. InstrumentationTestRunner es el ejecutor de casos de prueba que ejecuta el caso de prueba en la aplicación de destino.
  5. AndroidTestCase extiende JUnit TestCase. Contiene métodos para acceder a recursos como el contexto de actividad.
  6. ApplicationTestCase verifica las clases de aplicación en un entorno controlado.
  7. InstrumentationTestCase verifica una característica o comportamiento particular de la aplicación de destino, por ejemplo, verificar la salida de la interfaz de usuario de la aplicación.
  8. ActivityTestCase es una clase base que admite probar las actividades de la aplicación.
  9. ProviderTestCase es una clase para probar un solo ContentProvider.
  10. ServiceTestCase se utiliza para probar clases de servicio en un entorno de prueba. También es compatible con el ciclo de vida del servicio.
  11. SingeLauchActivityTestCase se utiliza para probar una sola actividad con un InstrumentationTestCase.
  12. ActivityUnitTestCase se utiliza para probar una sola actividad aislada.
  13. ActivityInstrumentationTestCase2 extiende la clase JUnit TestCase. Lo conecta a la aplicación de destino con instrumentación. Con esta clase, puede acceder al componente GUI de la aplicación y enviar un evento de IU (pulsación de tecla o evento táctil) a la IU.

A continuación se muestra un ejemplo de ActivityInstrumentationTestCase. Verifica el funcionamiento de la interfaz de usuario de la aplicación Calculadora, verifica la corrección de las salidas de la interfaz de usuario.

Ejemplo de prueba ActivityInstrumentationTestCase2

Marco de prueba roboeléctrico

Probar usando el marco de prueba de Android con un dispositivo o un emulador es difícil. La creación y ejecución de pruebas es lenta y requiere mucho esfuerzo de desarrollo. Para solucionar este problema, hay otra opción: el marco de prueba Robolectric .

El marco Robolectric le permite ejecutar pruebas de Android directamente en JVM sin la necesidad de un dispositivo o un emulador.

Funciones avanzadas de Robolectric

Clases de casos de prueba de roboeléctricos

Operación de Robolectric

  • Como se muestra arriba, Robolectric puede realizar las siguientes acciones:
  • Regístrese y cree una clase de sombra
  • Interceptar la carga de la clase de Android
  • Usa javaassist para anular los cuerpos del método de la clase de Android
  • Vincular el objeto Shadow a la clase de Android
  • Esto permite que el código bajo prueba se ejecute sin el entorno de Android.

Otros marco de prueba

Además de los marcos de prueba que se mencionaron anteriormente, existen muchos otros marcos de prueba como:

  • Android Junit Report, un ejecutor de pruebas de instrumentación personalizado para Android que genera informes XML para su integración con otras herramientas.
  • Expreso
  • Appium

Mitos de las pruebas de Android

Muchas empresas desarrollan estrategias de prueba de Android que se basan en conceptos erróneos comunes. Esta sección examina algunos mitos y realidades populares de las pruebas de Android.

Mito n. ° 1: todos los dispositivos Android son iguales ... la prueba en emuladores es suficiente

Comencemos con un ejemplo simple. Una aplicación funciona perfectamente en emuladores, pero en algunos dispositivos reales, se bloquea durante la ejecución.

La aplicación se bloquea durante la ejecución en un dispositivo real

Los emuladores no son suficientes para sus pruebas móviles. Debes probar tu aplicación en dispositivos reales.

Mito n. ° 2: las pruebas en algunos dispositivos comunes son suficientes

  • En diferentes dispositivos, su aplicación se ve diferente porque diferentes dispositivos tienen diferentes hardware, tamaños de pantalla, memoria, etc. Debe probar su aplicación en diferentes dispositivos, versiones de SO, redes de operadores y ubicaciones.

Mito n. ° 3: las pruebas exploratorias justo antes del lanzamiento son suficientes

  • Generalmente en todas las pruebas, diseñamos los casos de prueba y luego los ejecutamos. Pero en las pruebas exploratorias, el diseño y la ejecución de las pruebas se realizarán juntos.
  • En las pruebas exploratorias, no hay plan ni preparación, luego el evaluador haría las pruebas que él quisiera hacer. Algunas funciones se probarán repetidamente, mientras que algunas funciones no se probarán del todo.

Mito n. ° 4: si hay algunos errores en la aplicación, los usuarios entenderán

  • Si la aplicación no funciona y tiene errores, los usuarios desinstalan su aplicación
  • Los problemas de calidad son el primer motivo de una mala revisión en Google Play. Afecta a su reputación y pierde la confianza del cliente.

Por lo tanto, es esencial contar con una estrategia de prueba de Android adecuada.

Mejores prácticas en pruebas de Android

  • Los desarrolladores de aplicaciones deben crear los casos de prueba al mismo tiempo que escriben el código.
  • Todos los casos de prueba deben almacenarse en el control de versiones, junto con el código fuente.
  • Utilice la integración continua y ejecute pruebas cada vez que se cambie el código
  • Evite el uso de emuladores y dispositivos rooteados