Automatización de Pruebas en App Mobile con MonkeyTalk (y II)

En la anterior entrada hemos visto los primeros pasos para configurar un framework de automatización de pruebas para dispositivos móviles con Monkeytalk, ahora nos centraremos en las actividades propias del proceso de automatización como son la grabación de scripts, la construcción de casos de test, la ejecución y el análisis de resultados.

La selección de una herramienta adecuada a nuestros objetivos y que cubra las necesidades técnicas es un proceso de clave que debe ser evaluado en el momento que nos planteemos la automatización.

2 Framework de Automatización (cont.).

• Grabación:  Al igual que en cualquier otro proceso de automatización, la grabación de nuestros casos de prueba es una herramienta potente para obtener la base de nuestros scripts. En el caso de dispositivos móviles, la podemos realizar directamente desde un dispositivo (emulado o real), sobre un Sistema Operativo concreto (IOs o Android) y a través de diferentes conexiones entre nuestra herramienta y dispositivo sobre el que grabamos (USB, WiFi o Emulador).

Automatización de Pruebas en App Mobile con MonkeyTalk (I)

1 Introducción.

El éxito de las aplicaciones móviles, presenta uno de los mayores retos en el área de la automatización de pruebas: ¿cómo conseguir automatizar las pruebas funcionales con independencia de la tecnología de la app (Web o Nativa), del sistema operativo (Android, IOs, etc..) y del extraordinario número de terminales que se encuentran en el mercado?

Las ventajas que presenta la automatización se hacen mucho visibles cuando nos movemos en el mundo "mobile". La posibilidad de disponer de nuestros scripts listos para la ejecución en paralelo en un conjunto grande de dispositivos (reales o emulados) de diferentes características supone un ahorro de tiempo que sin lugar a dudas debe ser valorado adecuadamente. 

En el siguiente vídeo se puede observar el resultado de la "demo" que hemos preparado para elaborar esta entrada ejecutando una TestSuit automática de manera desatendida sobre dispositivos de muy diferentes características:

• Dispositivo Real Samsung Galaxy Trend con Android 4.0.
• Dispositivo Real Tablet Acer Iconia A100 con Android 4.0.
• Dispositivo Emulado Nexus 5 con Android 2.2.

En esta entrada vamos a ver un framework de automatización de pruebas para apps mobile con la herramienta de automatización MonkeyTalk, cuyas principales características son:

Loadrunner 11.5. Virtual User Generator, entendiendo conceptos

Como diria Fray Luis de León y su "como deciamos ayer.." , seguimos con este análisis de la herramienta Loadrunner en su versión 11.5 . Ahora, con el análisis de los cambios que se incluyen en su generador de scripts Virtual user Generator

1. Script y Solution. 
2. Diferencias de la interfaz
3. Ejecutando

Script y Solution

Nada más arrancar el Virtual User Generator podemos ver  que se nos presenta una interfaz algo alejada de la distribución en marcos de uso que veniamos viendo hasta las versiones 9.X.  La razón fundamental es que ahora el entorno está basado en la interfaz de entorno de compilación y desarrollo Eclipse .

Nada más iniciar la creación de un nuevo script que refleje una navegación a probar , podemos ver que se invoca un nuevo concepto "Solution". Por lo que hemos podido ver hasta ahora, , su utilidad radica en poder combinar varias navegaciones más allá del uso de subtransacciones y nuevos Action para reflejar un flujo lógico de uso .

Solution con un sólo script protocolo Siebel Web

Podemos incluso incluir en una sola "solution" varios script de distintos protocolos que

Loadrunner 11.5. Revisión caracteristicas y análisis

Introducción

De nuevo un saludo a nuestros lectores .Con la frenética periodicidad de un asteroide de extinción masiva (más o menos), os presentamos un nuevo artículo para el análisis.

Como ya habréis visto en otro de nuestros post, habitualmente tratamos con Loadrunner como herramienta para pruebas de carga. En fechas recientes, hemos tenido la oportunidad de utilizar la última versión de esta utilidad, lider en el mercado de herramientas profesionales, y compartir con los lectores nuestras impresiones y conclusiones .

Vamos a hacer un recorrido por el proceso de instalación y los principales cambios que hemos observado respecto a las versiones 8.X y 9.X  , así como sobre el manejo de los componentes más relevantes.

Instalación

 

Pasos previos

Hemos podido comprobar que , dada la naturaleza de los protocolos más demandados últimamente (AJAX, Siebel ... etc) se ha procedido por parte de HP a incluir,como paso previo a la instalación la autoejecución de los plugins y distribuibles relacionados con los mismos. 

En concreto vemos que ,automáticamente al inicio de la instalación, se ejecutan los MSI de

• Microsoft Visual C++  2005 ,2008 2010 Redistributable
• Microsoft .NET  Framework Cliet & Extended
• Microsoft WSE 2.0 (SP3) -3.0 Runtime

 

Proceso de instalación

No vamos a extendernos en demasía respecto a los pasos que se siguen durante el proceso de implementación de Loadrunner en un sistema ( la guia de instalación es muy completa y los pasos son guiados en su mayor parte ) ,pero sí que procederemos a dar nuestra impresión

El procesos de instalación por lo demás, es bastante similar al de versiones previas, permitiéndote instalar sólo lo que se necesite para el destino final de la máquina :

• Tipo estación de trabajo de desarrollo (Vugen )
• Inyector de carga (Loadrunner Agent)
• Completo (Controler, Analyzer, Vugen, Monitoring…etc)

Imagen 1: Menú instalación Loadrunner 11.5

Jmeter : Revista de actualidad . Revisando la versión 2.9

Saludos a todos los jotaemeteros. Como bien sabrán nuestros lectores habituales, la información proporcionada sobre la utilidad de pruebas Jmeter es una de las especialidades de este blog. Por lo que, siguiendo nuestra línea de oportunismo y descaro habituales, aprovecharemos para hacer un nuevo artículo que, creemos  será útil para los usuarios habituales y visitantes ocasionales.

Jmeter versión 9.

Analizamos en este post la última versión  disponible de Jmeter publicada en la web oficial. En concreto es la 2.9 r1437961

 

Introducción

En anteriores entradas de nuestro monográfico de Jmeter, hemos estado trabajando con las versiones 2.4 y 2.5.1 . Tras diversas experiencias en el día a día con las mismas sacamos algunas conclusiones acerca de su fiabilidad para pruebas con diversas navegaciones y en el aprovechamiento de recursos.

Estas conclusiones se pueden resumir en

• Un elevado uso de recursos en la ejecución de pruebas con el interfaz de usuario gráfico iniciado
• Problemas con la ejecución de escenarios que reflejen navegaciones múltiples de usuario.
• Falta de compatibilidad con scripts grabados con  versiones  distintas a la del inyector.
• Tasa de errores elevada de la versión 2.5.1 con peticiones HTTP sobre AJAX.

Sigue sin resolverse el problema de compatibilidad, siendo al parecer inherente a esta utilidad ,aunque ya desde la versión 2.8 ,se solventó el de las peticiones HTTP sobre AJAX

Cambios en el interfaz.

Hasta la versión 2.6 no se introdujo la “barra gráfica “ que adorna el interfaz de usuario de Jmeter. En este aspecto, no se observan prácticamente cambios entre versiones,salvo la marcada con el circulo rojo

Gráfica 1. Barra de herramientas UI JMeter v 2.6

Gráfica 2.Barra de herramientas UI JMeter v 2.9