Diferencias entre Herramientas de Test de Performance

Introducción
Básicamente hay dos maneras de obtener indicadores de performance:

  • Fijar los usuarios concurrentes y medir los tiempos de respuesta de uno o más pasos por llamada/s (la experiencia del usuario, la cantidad de usuarios que supuestamente soporto concurrentes en línea)
  • Fijar la tasa de requests que se quiere obtener y medir los tiempos de respuesta (la experiencia del server con los usuarios arriba intentando ver mi contenido)

Hay dos herramientas Open Source que se utilizan habitualmente para fijar la cantidad de usuarios (o threads concurrentes) y medir tiempo de respuesta:

ab (Apache Benchmarking)
Línea de comandos, normalmente instalado por default cuando se instala Apache.

JMeter (Apache JMeter)
Mucho más sofisticada. Interfaz gráfica, Java, permite hacer varios pasos por llamada y varias llamadas, parseo de regular expressions, graduar cantidad de threads concurrentes, etc.

Diferencias entre AB y JMeter
En caso de querer comparar los resultados de un test de stress entre estas diferentes herramientas con el objetivo de que los resultados sean similares se sugiere leer esta breve descripción:

1) El testing con JMeter se lo debe ejecutar teniendo destildado en la pantalla HTTP Request http Client el checkbox: Recuperar todos los recursos empotrados en el archivo HTML (retrieve all embedded resources from html files) dado que AB sólo hace la llamada al HTML y no a lo que el mismo tiene embebido.

2) En JMeter el tester coloca Número de Hilos (threads) que es la Concurrencia y cantidad de pedidos (requests) que repite un usuario; la multiplicación de ambas nos da la muestra total de la prueba. Ej: 10 hilos x 10 req/hilo = 100 req totales de las 10 concurrencias (total de la muestra).

Por otro lado Apache Benchmarking, en cambio se colocan los siguientes valores:
ab –n(valor) –c(valor) http://hostname:port/path

Donde a diferencia de JMeter –n no es la cantidad de request por usuario sino la cantidad total de request de toda la concurrencia, es decir lo que para JMeter es la muestra total, mientras que –c es la Concurrencia (o Grupo de Hilos para JMeter).

De esta manera, para que las pruebas en las diferentes herramientas, se ejecuten con el mismo nivel de carga con el objetivo de validar los resultados entre ambas se muestra el siguiente ejemplo:
En JMeter                                                        En AB
Prueba 1: 30 hilos x 1 req/hilo = 30               ab -n 30 -c 30 http://hostname:port/path
Prueba 2: 30 hilos x 10 req/hilo = 300         ab -n300 -c30 http://hostname:port/path
Prueba 3: 30 hilos x 100 req/hilo = 3000      ab -n3000 -c30 http://hostname:port/path

Usando una u otra herramienta, siempre se sugiere tener un panorama bien amplio y probar:

  • URL de Home
  • URL de Nota / Aviso / Post
  • URL inexistente (Error 404) como una forma de medir cuanto le cuesta al webserver resolverlo

En la otra vertiente de fijar requests/segundo se encuentra otra herramienta Open Source:

httperf
Línea de comandos, la estamos usando en combinación con autobench (un script para automatizar ejecuciones sucesivas de httperf.
Desde el punto de la estabilidad, el uso de httperf permite encontrar más rápidamente los puntos de saturación que con las otras herramientas suele disimularse. Fundamentalmente porque la carga es un producto de la cantidad de usuarios concurrentes por los requests que realiza cada uno. Así que fijar una carga de esta manera implica cantidad de usuarios pero también un comportamiento esperado. En cambio, la tasa de requests por segundo bruta es un indicador más directo del umbral que soporta el server y de los efectos bola de nieve que se producen cuando se encuentra la saturación. Permitiendo encontrar además otros indicadores paralelos en CPU y memoria, pudiéndose validar la cercanía a un punto de quiebre/saturación directamente en un access.log.

Claro que existen también herramientas pagas -algunas incluso muy costosas- pero entendemos que, a menos que necesitemos alguna funcionalidad específica que estas herramientas puedan proveer, para las pruebas básicas de Performance que podemos hacer desde Testing, las mencionadas arriba son más que suficientes.

Las principales ventajas:

  • Son gratuitas
  • No requieren de demasiado tiempo ni esfuerzo para dominar sus funcionalidades básicas
  • Ofrecen flexibilidad para obtener reportes e información de performance con diferentes indicadores

En próximos posts iremos profundizando sobre algunas de las pruebas de performance típicas, como planificarlas, ejecutarlas, reportar y los aspectos a tener en cuenta en cada una.

 

 

¿Anda bien?: Así probamos la actualización de la aplicación de TN en iOS y Android

banner

por Guillermo Alvis

No todas las aplicaciones que descargamos funcionan bien. Incluso, muchas de las que lo hacen tienen “oportunidades de mejora” que bordean la frontera con el “bug” o con la “usabilidad discutible”. Las “oportunidades de mejora” se pueden presentar en diferentes áreas: consumo de CPU, memoria o batería; problemas de performance, como puede ser el renderizado de imágenes; o simplemente pueden resultarle lentas a los usuarios.

 

Cuando publicamos nuestras nuevas aplicaciones, la comunicación se enfocó en el funcionamiento. “TN anda bien”, decíamos en las promociones. Y aunque quizás suene redundante porque todas las aplicaciones deberían “andar bien”, ahora queremos compartir con ustedes por qué desde el equipo de QA de TN creemos en eso.

Este fue uno de los proyectos más desafiantes que asumimos por la complejidad de los escenarios a testear. En el plan de pruebas contemplamos:

Pruebas de Performace de la App

Concentramos la mayor cantidad de pruebas sobre el uploader de imágenes y videos de TN y la Gente para realizar publicaciones en bulk (de hasta 1000 usuarios simultáneos).

Para llevar a cabo estas pruebas se tuvo que superar un “desafío técnico” que pudo lograr nuestro equipo de Desarrollo. El mismo tenía que ver con estresar el uploader. Había que contemplar que no podíamos usar los mismos archivos files.json en los que se particiona un video, debido a que cada uno tiene información única e irrepetible vinculada al archivo de video original. En síntesis: no se podía reutilizar el mismo set de archivos y agregarle concurrencia.

Pruebas funcionales y de performace de los servicios .JSON que usa la App

  • Desde lo funcional se probaron todos los servicios .JSON (tanto GET como POST) para constatar que trajeran de manera correcta toda la información requerida.
  • Desde el stressing se probaron todos los servicios con JMeter con altos niveles de concurrencia para ver cómo respondían.

 

Pruebas de performance de la app con diferentes anchos de banda de conectividad de red

Se probó con: 4G, 3G, Edge y 2G. Esto se pudo llevar a cabo mediante el uso de una herramienta llamada Charles, que es paga pero barata (¡Je!) pero que además nos permite apuntar la aplicación, al ambiente en el que quisiéramos probar (Desa/Test/Prepro).

Pruebas de performance de la app en los equipos

Se ejecutó el test en los equipos Android más avanzados, con las siguientes “Opciones de Desarrollador” activas:

  • Mostrar superposición de GPU
  • Si / No: conservar actividades

 

Pruebas funcionales de la App

Para estas pruebas se utilizó el siguiente set de dispositivos:

Los dispositivos en los que probamos la actualización

En estos equipos se realizó un conjunto de pruebas funcionales que consolidamos en un checklist. Para los uploaders de imágenes y videos se usaron todos los formatos no nativos de cada uno de los dispositivos. Para las pruebas del upload de fotos de TN y la Gente se contemplaron: .gif, .png, .tif, .bmp y .jpg; mientras que para el upload de video se usaron: .mp4, .3gp, .flv, .mov, .avi, .mpg y .wmv.

Con eso se consiguió un gran nivel de cobertura entre dispositivos y formatos de archivo.

Testing de las nuevas funcionalidades de video

La nueva versión de la aplicación incorpora dos novedades respecto al video tanto en iOS como en Android. Estos últimos desarrollos le permite al usuario visualizar los videos de una nota sin tener que salir de la portada, con players bien simples que se cargan de manera dinámica y automática a medida que el usuario va descubriendo el contenido.

La señal de TN en vivo se reproduce en un nuevo player de pantalla completa también integrado a la App. El usuario accede a la transmisión con un solo botón y sin demoras. Creemos que esto la convierte en una aplicación ideal para informarse con rapidez y comodidad.

El desarrollo tuvo como objetivo la usabilidad y la mejora de la experiencia en video que muchos usuarios criticaron en los stores. Para eso el equipo de diseño y desarrollo trabajó en los detalles y realizando pruebas con usuarios para poder consolidar mejores resultados.

Informe del estado de la App con Monkop

Monkop es una herramienta para el test de Apps en Android (hay versiones pagas y una free). Se encuentra en “la nube” y sólo debe subirse el .apk de instalación de la app a testear. Luego se encarga de enviarnos un reporte con los resultados de las pruebas, donde brinda información muy útil al equipo de desarrollo porque sugiere oportunidades de mejora del orden de performance, uso de CPU, memoria y energía, entre otras.

Todas estas tareas del equipo de QA, sumadas al trabajo de los desarrolladores de aplicaciones y el área de producto explican, a mi criterio, porque la App de TN ¡anda bien!

¿A ustedes qué les parece? ¿Ya la probaron? Les dejo los enlaces al store de iOS y Android para que la descarguen.

 Post publicado originalmente en: http://blogs.tn.com.ar/dev/anda_bien_asi_probamos_la_actualizacion_de_la_aplicacion_de_tn_en_ios_y_android/

2 años de Tests de Performance en TN

Desde QA (aka Quality Assurance) trabajamos para mejorar la calidad de lo que producimos. Un ejemplo es el proceso de tests de performance que venimos haciendo desde hace tiempo en éste proyecto de TN que tanto queremos.

Antes que nada, es necesario aclarar las diferencias entre los tipos de pruebas de performance. No todas son iguales ni tienen los mismos objetivos.

  1. Test de carga: prueba de largo plazo de la aplicación con el caudal de tráfico de datos y usuarios habituales, los cuales llamamos concurrencia.
  2. Test de volumen: prueba de más corto plazo de la aplicación pero con un caudal mayor de tráfico de datos y concurrencia.
  3. Test de stress: su objetivo es conocer el “punto de quiebre” del sistema, ya sea en términos de hardware como de software. Es saber hasta donde “se la aguanta”. Para eso hacemos pruebas con niveles verdaderamente grandes de usuarios concurrentes, en los cuales simulamos acciones en el sitio y consumo de diferentes servicios.

Básicamente hay 2 maneras de obtener indicadores de performance:

  1. Fijar los usuarios concurrentes y sus repeticiones de acciones para medir los tiempos de respuesta de las llamadas (la experiencia de usuario, la cantidad de usuarios concurrentes que supuestamente soporta el sistema)
  2. Fijar la tasa de requests que se quiere obtener y medir los tiempos de respuesta (la experiencia del server con los usuarios arriba intentando ver mi contenido)

Para realizar éste tipo de pruebas usamos una gran herramienta llamada Apache JMeter. Está hecha en Java, cuenta con interfaz gráfica y permite hacer varios pasos por llamada como también varias llamadas al mismo tiempo. También permite realizar parseo de expresiones regulares, graduar la cantidad de threads (hilos) concurrentes y un montón de cosas más.

JMeter simula carga en el servidor y permite estresar diferentes tipos de peticiones: HTTP, HTTPS, JSON, SQL, SMTP, LDAP y SOAP/XML como WebService SOAP. Además es Open Source, que no es un detalle menor. Este es un ejemplo de lo que podemos hacer con la herramienta:

graficos

Son los resultados de pruebas de stress ejecutadas sobre la home, la nota interna y los servicios más importantes que consume el sitio de TN. Todas fueron realizadas en entornos Beta (pre-lanzamiento). La primera corresponde al rediseño presentado en agosto de 2013; la segunda son pruebas actuales que incluyen la migración a Drupal 7.

Como se puede ver a simple vista, el trabajo constante que hacen los equipos de Desarrollo y Operaciones en performance da sus frutos. En los últimos 2 años los avances en los servicios son notorios, llegando a valores de mejora de 3000% más rápidos y eficientes. Eso quiere decir que están muy bien preparados para acompañar al crecimiento del consumo móvil de TN.

Nota del autor: originalmente publicado en el Blog de Todo Noticias