Cómo diseñar casos de prueba de aplicaciones de Android
Uno de los mayores desafíos que enfrentan los desarrolladores comunes de Android en su trabajo diario es la amplia gama de dispositivos finales y versiones de [url=]sistema operativo[/url]. Un estudio realizado por OpenSignal mostró que en julio de 2013 había más de 11.828 dispositivos finales Android diferentes en el mercado, todos los cuales diferían en tipo/tamaño/resolución de pantalla, así como en configuraciones específicas. Teniendo en cuenta que la encuesta del año anterior sólo registró 3.997 dispositivos diferentes, este es un obstáculo creciente.
Desde la perspectiva del desarrollo de APP móviles, existen cuatro características básicas que definen a los equipos terminales:
1. Sistema operativo: versión del sistema operativo Android (1.1~4.3) definida profesionalmente por el "índice API" (1~18).
2． Monitor: una pantalla se define principalmente por la resolución de la pantalla (medida en píxeles), la densidad de píxeles de la pantalla (medida en DPI) y/o el tamaño de la pantalla (medido en pulgadas).
3． CPU: La "Interfaz binaria de aplicación" (ABI) define el conjunto de instrucciones de la CPU. La principal diferencia aquí son las CPU basadas en ARM e Intel.
4． Memoria: un dispositivo consta de memoria interna (RAM) y un montón predefinido de memoria virtual Dalvik (montón VM).
Son las dos primeras características, sistema operativo y pantalla, las que requieren especial atención, ya que son directamente visibles para el usuario final y deben ser cubiertas de forma constante y rigurosa mediante pruebas. En cuanto a las versiones de Android, en julio de 2013 había ocho versiones diferentes en el mercado ejecutándose simultáneamente, lo que provocó una fragmentación inevitable. En julio, casi el 90% de estos dispositivos, el 34,1% ejecutaban versiones Gingerbread (2.3.3-2.3.7), el 32,3% ejecutaban Jelly Bean (versión 4.1.x) y el 23,3% ejecutaban Ice Cream Sandwich (4.0. 3 - 4.0.4).
En cuanto a las pantallas de los dispositivos, un estudio de TechCrunch de abril de 2013 mostró que la gran mayoría (79,9%) de los dispositivos activos utilizaban pantallas "normales" de tamaños de 3 y 4,5 pulgadas. Las densidades de pantalla de estos dispositivos varían entre "MDPI" (~160 DPI), "hdpi" (~240 DPI) y "xhdpi" (~320 DPI). Hay excepciones, un dispositivo que representa sólo el 9,5% tiene una densidad de pantalla "hdpi" baja (~120 DPI) y una pantalla pequeña.
Si se ignora esta diversidad en el proceso de control de calidad, es absolutamente previsible: aparecerán errores en la aplicación, seguidos de una tormenta de informes de errores y, finalmente, reseñas negativas de los usuarios en Google Play Store. Entonces, la pregunta que nos ocupa es: ¿Cómo se resuelve realmente este desafío utilizando un nivel razonable de esfuerzo de prueba? Definir casos de prueba y un proceso de prueba que los acompañe es un arma eficaz para afrontar este desafío.
Casos de uso: "¿Dónde probar", "Qué probar", "Cómo probar", "Cuándo probar"?
"Dónde probar"
Para ahorrarle el costoso tiempo dedicado al trabajo de prueba, recomendamos reducir primero las 32 combinaciones de versiones de Android mencionadas anteriormente y que representan el mercado de 5 a 10. Versiones de las principales pantallas de dispositivos en uso. Al seleccionar dispositivos de referencia, debe asegurarse de cubrir una gama suficientemente amplia de versiones y tipos de pantalla. Como referencia, puede utilizar la encuesta de OpenSignal o la infografía Uso de la detección de teléfonos móviles [3] para ayudar a seleccionar los dispositivos más utilizados.
Para satisfacer la curiosidad, el tamaño y la resolución de la pantalla se pueden asignar desde la documentación de Android [5] a la densidad de los datos anteriores ("ldpi", "mdpi", etc.) y la resolución ( "pequeño", "estándar", etc.).
Con la ayuda del estudio de detección de teléfonos móviles de 2013, es fácil encontrar una serie de dispositivos representativos.
Aquí hay una curiosidad interesante: el 30% de los usuarios indios de Android tienen dispositivos con una resolución muy baja de sólo 240×320 píxeles y, como puedes ver en la lista anterior, el Samsung Galaxy Y S5360 se encuentra entre ellos. Además, ahora se utilizan con mayor frecuencia píxeles de resolución de 480 × 800 (como se ve en el Samsung Galaxy S II en la tabla anterior).
"Qué probar"
La aplicación móvil debe proporcionar la mejor experiencia de usuario y una variedad de teléfonos inteligentes y tabletas en diferentes tamaños y resoluciones (la palabra clave "diseño responsivo") se muestra correctamente en la computadora (prueba de UI). Al mismo tiempo, las aplicaciones deben ser funcionales y compatibles (pruebas de compatibilidad) con tantas especificaciones del dispositivo como sea posible (memoria, CPU, sensores, etc.). Junto con los problemas de fragmentación "directos" previamente adquiridos (con respecto a la versión de Android y las características de la pantalla), la fragmentación "relacionada con el contexto" juega un papel decisivo. Esta función implica muchas situaciones o entornos diferentes en los que los usuarios utilizan dispositivos finales en su propio entorno. Por ejemplo, si la conexión de red es inestable, las llamadas se interrumpen, la pantalla se bloquea, etc., debe considerar cuidadosamente las pruebas de estrés [4] y las pruebas exploratorias para asegurarse de que nada salga mal.
Es necesario preparar con antelación todos los escenarios de prueba posibles que cubran las funciones más utilizadas de la aplicación. La detección temprana de errores y modificaciones simples en el código fuente solo se pueden lograr mediante pruebas continuas.
"Cómo probar"
Una forma pragmática de tener en cuenta esta amplia variedad es que los emuladores de Android proporcionen una herramienta ajustable que sea casi dispositivos de usuario final que puedan emular Android en una computadora estándar. En resumen, el emulador de Android es una herramienta ideal para pruebas de regresión continua (pruebas de interfaz de usuario, unitarias y de integración) con varias configuraciones de dispositivos (pruebas de compatibilidad) en el proceso de control de calidad. Para pruebas exploratorias, el simulador se puede configurar en una amplia gama de escenarios diferentes. Por ejemplo, el emulador se puede configurar de manera que simule cambios en la velocidad o calidad de la conexión. Sin embargo, el control de calidad en dispositivos reales es indispensable. En la práctica, el dispositivo virtual utilizado como referencia aún puede diferir en pequeños aspectos (pero para algunas aplicaciones muy importantes), como no proporcionar ajustes específicos de la aplicación en el sistema operativo Android o no admitir auriculares y Bluetooth. El rendimiento en hardware real juega un papel importante en el proceso de evaluación y también debe probarse en todos los dispositivos finales posibles (pruebas de usabilidad) teniendo en cuenta aspectos como la compatibilidad del hardware táctil y la forma física del dispositivo.
"Cuándo probar"
Ahora que hemos definido dónde probar (dispositivo de referencia), qué probar (escenario de prueba) y cómo probar (emulador de Android y dispositivo real). ), es crucial delinear un proceso y determinar cuándo ejecutar qué escenario de prueba. Por lo tanto, recomendamos el siguiente proceso de dos niveles:
1. Pruebas de regresión con dispositivos virtuales.
Esto incluye pruebas de regresión automatizadas continuas en dispositivos de referencia virtuales para identificar errores fundamentales en una etapa temprana. La idea aquí es identificar errores de forma rápida y rentable.
2． Pruebas de aceptación con equipos reales.
Esto implica: Pruebas intensivas (principalmente pruebas manuales) en dispositivos reales antes de lanzarlos a Google Play Store durante la "promoción de planificación" (por ejemplo, grupo de pruebas alfa y beta).
En la primera fase, la automatización de pruebas ayuda enormemente a implementar esta estrategia de forma rentable. En esta etapa, sólo se pueden incluir casos de prueba que puedan automatizarse fácilmente (es decir, que puedan ejecutarse diariamente).
Este tipo de prueba automatizada proporciona una red de seguridad para los desarrolladores y evaluadores durante el desarrollo continuo de una aplicación. Las pruebas de rutina garantizan que la funcionalidad principal funcione correctamente, que la estabilidad general y la calidad de la aplicación se reflejen de forma transparente en los datos de las pruebas y que las regresiones de certificación se puedan correlacionar fácilmente con los cambios recientes.
Estas pruebas se pueden diseñar y registrar fácilmente desde la computadora del evaluador utilizando una solución SaaS como la aplicación móvil UI Testing in the Cloud de TestObject.
Si y sólo si esta fase se ha ejecutado con éxito, el proceso continúa con pruebas que requieren mucha mano de obra en la segunda fase. La idea aquí es invertir recursos de prueba solo si la funcionalidad principal pasa las pruebas automatizadas, lo que permite a los evaluadores centrarse en escenarios avanzados. Esta fase puede incluir casos de prueba como pruebas de rendimiento, pruebas de usabilidad o pruebas de compatibilidad. La combinación de estos dos métodos produce una poderosa estrategia de control de calidad para aplicaciones móviles [7].