Android Tutorial de prueba de aplicaciones con marco de automatización

¿Por Qué Elegir un Agente de Compras de Yiwu? 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 invierta en el diseño y la implementación, los errores son inevitables y aparecerán errores.

Android Estrategia de prueba

Una estrategia de prueba de Android correcta debe incluir lo siguiente

1. Prueba unitaria
2. Examen de integración
3. Operaprueba nacional
4. Prueba del sistema

Pruebas unitarias

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

Android La plataforma viene preintegrada. junit Marco 3.0. Es un marco de código abierto para la automatización. Examen de la unidad. Android Testing Framework es una herramienta poderosa para que los desarrolladores escriban un programa de prueba unitario eficaz.

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 UI garantizan que su aplicación devuelva la salida de UI correcta en respuesta a la secuencia de acciones del usuario en el dispositivo.

La forma común de realizar pruebas de IU en el dispositivo es Android Instrumentación. Pero esto tiene problemas de rendimiento. Una de las mejores herramientas para realizar pruebas de UI en Android is robótico.

Pruebas de integración

In Pruebas de integración, todos los módulos probados por unidad, se combinan y verifican. En Android, las pruebas de integración a menudo implican verificar la integración conAndroid componentes como pruebas de servicio, pruebas de actividad, pruebas de proveedor de contenido, etc.

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

Operapruebas opcionales

• Operacionales 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.
• In Android, Fitness es un marco de código abierto que facilita la realización de pruebas operativas para 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 vista de seguimiento realizar pruebas de rendimiento en Android .Esta herramienta puede ayudarle a depurar su aplicación y perfilar su rendimiento.

PRUEBAS DE ANDROID Automatizadas

Como Android está fragmentado, es necesario realizar pruebas en una multitud de dispositivos, pero esto también te costará dinero. Android Las pruebas 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 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 aplicación es Android marco de prueba. Es un marco de prueba potente y fácil de usar que está bien integrado con el Android Herramientas SDK.

1. Paquete de aplicación es su aplicación de destino la que necesita ser probada
2. InstrumentaciónTestRunner son los Caso de prueba corredor que ejecuta el caso de prueba en la aplicación de destino. Incluye:

2a) Herramientas de prueba: Un SDK de herramientas para la creación de pruebas. Están integrados en Eclipse IDE o ejecutar como línea de comando.

2b) Corredor de monos: Una herramienta que proporciona API para escribir programas que controlan un Android dispositivo o emulador fuera de Android código.

3. Paquete 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.midominio.miaplicación", entonces el paquete de prueba debe ser "com.midominio.miaplicación.prueba". 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.

Android Clases de casos de prueba

1. Caso de prueba incluye JUnit métodos para ejecutar JUnit test
2. Banco de pruebas se utiliza para ejecutar un conjunto de casos de prueba
3. InstrumentaciónTestSuite es un TestSuite que inyecta Instrumentación en InstrumentationTestCase antes de ejecutarlos.
4. InstrumentaciónTestRunner es el corredor de casos de prueba que ejecuta el caso de prueba en la aplicación de destino.
5. AndroidCaso de prueba Se extiende JUnit Caso de prueba. Contiene métodos para acceder a recursos como Activity Context.
6. Caso de prueba de aplicación verifica las clases de aplicación en un entorno controlado.
7. InstrumentaciónTestCase verifica una característica o comportamiento particular de la aplicación de destino, por ejemplo, verifica la salida de la interfaz de usuario de la aplicación.
8. Caso de prueba de actividad es una clase base que admite la prueba de las actividades de la aplicación.
9. Caso de prueba del proveedor es una clase para probar un único ContentProvider.
10. Caso de prueba de servicio se utiliza para probar clases de servicio en un entorno de prueba. También respalda el ciclo de vida del Servicio.
11. Caso de prueba de actividad SingeLauch se utiliza para probar una sola actividad con un InstrumentationTestCase.
12. ActivityUnitTestCase se utiliza para probar una sola actividad aislada.
13. ActividadInstrumentaciónTestCase2 extiende el JUnit Clase de caso de prueba. Le conecta a la aplicación de destino con instrumentación. Con esta clase, puede acceder al componente GUI de la aplicación y enviar eventos de UI (pulsación de tecla o evento táctil) a la UI.

A continuación se muestra un ejemplo de ActivityInstrumentationTestCase. Verifica el funcionamiento de la interfaz de usuario de la aplicación Calculator y comprueba la corrección de las salidas de la interfaz de usuario.

Marco de pruebas roboeléctricas

Prueba usando Android Probar el marco 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: Roboeléctrico marco de prueba.

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

Clases de casos de prueba roboeléctrica

• Como se muestra arriba, Robolectric puede realizar las siguientes acciones:
• Regístrate y crea una clase de Sombra
• Interceptar la carga de Android clase
• Utiliza javaassist para anular 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 Android ambiente.

Otros marcos de prueba

Además de los marcos de prueba mencionados anteriormente, existen muchos otros marcos de prueba como:

• Android Informe de Junit, un ejecutor de pruebas de instrumentación personalizado para Android que genera informes XML para integración con otras herramientas.
• Café Expreso
• 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 #1:Todos Android los dispositivos son iguales… probar en emuladores es suficiente

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

Los emuladores son insuficiente para tus pruebas móviles. Debes probar tu aplicación en dispositivos reales.

Mito n.º 2: realizar pruebas en algunos dispositivos comunes es suficiente

• En diferentes dispositivos, su aplicación se ve diferente porque diferentes dispositivos tienen diferente hardware, tamaños de pantalla, memoria, etc. Debe probar su aplicación en diferentes dispositivos, versiones de sistema operativo, 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 todos juntos.
• En las pruebas exploratorias, no hay ningún plan ni preparación, entonces el evaluador haría las pruebas que quisiera hacer. Algunas funciones se probarán repetidamente, mientras que otras no se probarán por completo.

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 el primer motivo de malas críticas en Google Play. Afecta 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 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 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