Android Tutorial de pruebas de aplicaciones con marco de automatización
Tomas Hamilton
⚡ Resumen inteligente
Android Las pruebas de aplicaciones verifican una compilación en un entorno de dispositivos fragmentado, combinando comprobaciones unitarias, de integración, operativas y del sistema con marcos de automatización que se ejecutan en un dispositivo o directamente en la JVM.
Por qué Android ¿Pruebas?
Android es el sistema operativo más grande del mundo. Al mismo tiempo, Android está fragmentado: hay toneladas de dispositivos y Android versiones con las que su aplicación debe ser compatible.
No importa cuánto tiempo inviertas en el diseño y la implementación, los errores son inevitables y aparecerán fallos.
Android Estrategia de prueba
Un correcto Android La estrategia de pruebas debe incluir lo siguiente:
- Prueba unitaria
- Examen de integración
- Operaprueba nacional
- Prueba del sistema
Pruebas unitarias
Las pruebas unitarias son conjuntos de programas diseñados para verificar una unidad atómica de código fuente, como un método o una clase.
El Android La plataforma viene preintegrada con la JUnit Marco 3.0. Es un marco de código abierto para automatizar Examen de la unidady permite a los desarrolladores escribir programas de pruebas unitarias eficaces.
Un complemento a las pruebas unitarias son las pruebas de interfaz de usuario (UI). Estas abarcan los componentes de la interfaz de usuario de la aplicación objetivo y garantizan que esta devuelva el resultado correcto para una secuencia de acciones del usuario en el dispositivo.
La forma habitual de realizar pruebas de interfaz de usuario en un dispositivo es Android Instrumentación. Pero esto tiene problemas de rendimiento. Una de las mejores herramientas para realizar pruebas de UI en Android is Robotium.
⚠️ Nota de versión: JUnit 3 clases como InstrumentaciónTestCase fueron obsoletos en la API 24; los proyectos actuales utilizan AndroidPrueba X, Espresso y UI Automator. Robotium No ha tenido ningún lanzamiento desde 2016.
Pruebas de integración
In Pruebas de integración, todos los módulos probados unitariamente se combinan y verifican. En Android Esto a menudo implica comprobar la integración con componentes como el Servicio, la Actividad y las pruebas del Proveedor de Contenido.
Muchos marcos de prueba se utilizan para realizar pruebas de integración para Android, como Troyd, Robolectric y Robotium.
Operapruebas opcionales
OperaLas pruebas funcionales, también llamadas pruebas de aceptación, son pruebas de alto nivel que verifican la integridad y la corrección de la aplicación.
In Android, Fitness Es un marco de código abierto que facilita la ejecución de pruebas operativas en la aplicación de destino.
Pruebas del sistema
In Pruebas del sistema Se prueba el sistema en su conjunto y se comprueba la interacción entre los componentes, software y hardware.
In Android, Las pruebas del sistema normalmente incluyen
- pruebas de GUI
- Pruebas de usabilidad
- Pruebas de rendimiento
- Pruebas de estrés
En la lista anterior, Test de rendimiento se le da más atención. Puedes utilizar herramientas como Tracrepasar realizar pruebas de rendimiento en AndroidEsta herramienta puede ayudarte a depurar tu aplicación y analizar su rendimiento. Traceview ahora está obsoleto en favor de Perfilador de CPU.
Automático Android Pruebas
As Android está fragmentado, es necesario realizar pruebas en muchos dispositivos y eso cuesta dinero. Automatizado Android Las pruebas ayudan a reducir esos costos.
Beneficios de la automatización Android las pruebas
- Reducir el tiempo de ejecución de casos de prueba.
- Aumente la productividad de su proceso de desarrollo
- Detección temprana de errores, ahorre costes en mantenimiento del software
- Encontró y corrigió rápidamente los errores en la implementación.
- Garantizar la calidad del software.
Estudiaremos los siguientes 2 marcos
- Android Marco de prueba
- Marco de pruebas roboeléctricas
Android marco de prueba
Uno de los marcos de prueba estándar para Android Las aplicaciones son la Android marco de pruebas. Está bien integrado con el Android Las herramientas SDK y su arquitectura constan de tres partes.
- El paquete de la aplicación es la aplicación objetivo que necesita ser probada.
- InstrumentationTestRunner es el Caso de prueba Ejecutor que ejecuta casos de prueba en la aplicación de destino. Incluye:
- Herramientas de prueba: Herramientas SDK para la creación de pruebas. Se integran en el IDE o se ejecutan desde la línea de comandos.
- Corredor de monos: Una herramienta que proporciona API para escribir programas que controlan un Android dispositivo o emulador fuera de Android código.
- El paquete de pruebas se organiza en proyectos de prueba y sigue una convención de nomenclatura. Si la aplicación bajo prueba tiene el nombre de paquete “com.mydomain.myapp”, entonces el paquete de pruebas debe ser “com.mydomain.myapp.test”. El paquete de pruebas incluye 2 objetos:
- Clases de casos de prueba: Incluir métodos de prueba que se ejecutarán en la aplicación de destino.
- Objetos simulados: Incluir datos simulados que se utilizarán como entrada de muestra para los casos de prueba.
Android Clases de casos de prueba
- El caso de prueba incluye JUnit métodos para ejecutar JUnit compruébalo
- TestSuite se utiliza para ejecutar un conjunto de casos de prueba.
- InstrumentationTestSuite es un conjunto de pruebas que inyecta instrumentación en InstrumentationTestCase antes de ejecutarlas.
- InstrumentationTestRunner ejecuta casos de prueba en la aplicación de destino.
- AndroidTestCase extiende JUnit Caso de prueba con métodos para acceder a recursos como el contexto de la actividad.
- ApplicationTestCase verifica las clases de la aplicación en un entorno controlado.
- InstrumentationTestCase verifica una característica o comportamiento específico, por ejemplo, la salida de la interfaz de usuario de la aplicación.
- ActivityTestCase es la clase base que permite probar las actividades de la aplicación.
- ProviderTestCase es una clase para probar un único ContentProvider.
- ServiceTestCase prueba las clases de servicio en un entorno de prueba y admite el ciclo de vida del servicio.
- SingleLaunchActivityTestCase se utiliza para probar una única actividad con un InstrumentationTestCase.
- Caso de prueba de la unidad de actividad Se utiliza para probar una actividad aislada individual.
- Caso de prueba de instrumentación de actividad2 extiende el JUnit La clase TestCase te conecta con la aplicación de destino mediante instrumentación, de modo que puedes acceder a los componentes de la interfaz gráfica de usuario y enviar eventos de la interfaz de usuario, como pulsaciones de teclas o toques.
A continuación se muestra un ejemplo de ActivityInstrumentationTestCase. Este verifica el funcionamiento de la interfaz de usuario de una aplicación de calculadora y comprueba la corrección de los resultados de la interfaz.
Marco de pruebas roboeléctricas
Pruebas utilizando el Android Realizar pruebas con un dispositivo o emulador es complicado. Crear y ejecutar pruebas es lento y requiere mucho esfuerzo de desarrollo. Para solucionar este problema, existe otra opción: el entorno de pruebas Robolectric.
Robolectric te permite ejecutar Android Realiza pruebas directamente en la JVM sin necesidad de un dispositivo o un emulador.
Clases de casos de prueba roboeléctrica
Robolectric puede realizar las siguientes acciones:
- Regístrate y crea una clase de Sombra
- Interceptar la carga de Android clase
- Usos Javaayudar a sobrescribir los cuerpos de los métodos de Android clase
- Vincular el objeto Sombra a Android clase
Esto permite que el código bajo prueba se ejecute sin un Android ambiente.
Otros marcos de prueba
Además de los marcos de prueba mencionados anteriormente, existen muchos otros, como por ejemplo:
- Android Informe de Junit, un ejecutor de pruebas de instrumentación personalizado para Android que genera informes XML para integración con otras herramientas.
- Espresso
- Appium
Mitos de Android Pruebas
Muchas empresas desarrollan Android Pruebas estrategias que se basan en conceptos erróneos comunes. Esta sección examina algunos mitos y realidades populares de Android pruebas.
Mito n.° 1: Todos Android Los dispositivos son iguales, por lo que realizar pruebas en emuladores es suficiente.
Una aplicación puede funcionar perfectamente en emuladores, pero fallar durante su ejecución en algunos dispositivos reales.
Los emuladores no son suficientes para probar tu aplicación en dispositivos móviles. Debes probarla en dispositivos reales.
Mito n.° 2: Probar en algunos dispositivos comunes es suficiente.
Tu aplicación se ve diferente en distintos dispositivos debido a las diferencias en el hardware, el tamaño de la pantalla y la memoria. Realiza pruebas en diversos dispositivos, versiones del sistema operativo, redes de operadores y ubicaciones.
Mito n.° 3: Las pruebas exploratorias justo antes del lanzamiento son suficientes.
- En la mayoría de las pruebas, diseñamos los casos de prueba y luego los ejecutamos; en las pruebas exploratorias, el diseño y la ejecución se realizan simultáneamente.
- No hay ningún plan ni preparación, así que el evaluador ejecuta las pruebas que le parece conveniente. Algunas funciones se prueban repetidamente, mientras que otras nunca se prueban.
Mito n.° 4: Si hay algunos errores en la aplicación, los usuarios lo entenderán.
- Si la aplicación no funciona y tiene errores, los usuarios la desinstalan.
- Los problemas de calidad son la principal razón de las malas críticas en Google Jugar daña tu reputación y hace perder la confianza de los clientes.
Por lo tanto, es esencial tener un adecuado Android Estrategia de pruebas establecida.
Mejores prácticas en Android Pruebas
- 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 un sistema de 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 depender únicamente de emuladores y dispositivos rooteados; confirme los resultados en hardware real con un inspector como uiautomatorviewer
