Errores más comunes al realizar Pruebas de Performance – Parte I


En esta primera parte (de la que serán varias entregas 😉 ) vamos a estar repasando algunos de los errores mas típicos al momento de realizar pruebas de Performance sobre una aplicación. Algunos de los errores que van a ver fueron sacados de la Web y el resto son por experiencia propia.

Si bien algunos puntos pueden llegar a discutirse, la lista es la siguiente:

Error 1: Arrancar tarde con las pruebas

Este es el mayor de los errores que me ha tocado vivir, no por decisión propia, sino porque las empresas se acuerdan de las pruebas de Performance una vez que entregan el producto al cliente y el cliente se queja por los tiempos de respuesta altísimos de la aplicación. Otra de las razones por las cuales se arranca tarde es porque confunden el Performance Testing o Load Testing con el Testing Funcional, lo cual es un grave error.

Las Pruebas de Performance o las Pruebas de Carga pueden realizarse sin que la aplicación este estable o este terminada la interfaz de usuario. Como mayormente (cerca del 80% de las veces) los problemas de Performance residen en la arquitectura o tecnología adoptadas descubrirlo una semana antes a la entrega puede causar dolor de cabeza a más de un PM o Vendedor ya que el costo del error es altísimo, provocando cambios en fechas de entrega y desconcierto en como solucionar el problema. Para poder visualizar estos problemas desde el comienzo existen practicas como PASA o planificar las tareas de performance como cualquier otra tarea paralela al desarrollo de la aplicación con objetivos y metas los cuales pueden ser administrados. En cuanto a que primero se necesita tener una aplicación para luego hacer pruebas de Performance, hay que tener en cuenta q las herramientas de Performance solo necesitan un servidor que pueda manejar las peticiones HTTP para los caminos más importantes, no es necesario que tenga una linda interfaz o cualquier otra cosa que tienen comúnmente las aplicaciones Web por lo que las pruebas podrían planificarse para ser realizadas a medida que avanza el desarrollo para que el costo de los errores sea menor.

Error 2: Pensar que puede ser realizado por una sola persona

Este es un error muy típico de aquellos tester funcionales que quieren incurrir en otras técnicas (es una muy buena actitud 😉 ) o reciben la orden de algún PM (con poco conocimiento técnico del testing o que recibió ese pedido del cliente y acepto sin conocer) y creen  que las pruebas de Performance pueden ser llevadas a cabo por una sola persona.

En cada caso nos podemos encontrar con los siguientes problemas:

  • No se cuenta con la capacidad necesaria: Para realizar las pruebas es necesario tener un conocimiento de la herramienta que se utiliza, las técnicas y metodologías junto al conocimiento sobre las pruebas de performance en sí.
  • Desconoce el código: Es necesario que la persona que desarrolló el código que causa los problemas de performance forme parte de las pruebas para que ofrezca un análisis del problema y posibles soluciones.
  • El ambiente en que corre las pruebas no es el indicado: Sin la ayuda de las personas a cargo del hardware de la empresa puede ser que las pruebas se desarrollen sobre un servidor que genere resultados totalmente erróneos con la realidad de la aplicación.

Error 3: Confundir Load Testing con cualquier otra cosa

Las pruebas de carga básicamente apuntan a verificar la performance de la aplicación o sistema, bajo una carga de trabajo en simultáneo.

Load Testing esta muy lejos del Testing Funcional. Ya que las metas de cada tipo de prueba son diferentes, las habilidades necesarias para realizar las pruebas son diferentes, los casos de prueba son diferentes, las herramientas y tecnologías son diferentes, casi siempre la metodología del proceso de pruebas son diferentes.

Load Testing no se trata de verificar la performance de la aplicación ante un solo usuario. Es obvio que los tiempos de respuesta de un camino end-to-end no van a ser los mismos si en la aplicación se encuentra realizándolo un usuario a que si se encuentran mas de 1 usuario. Pero hay que tener en cuenta que el componente que es el cuello de botella o baja en performance de la aplicación puede ser distinto cuando hay un solo usuario a cuando hay mas de un usuario.

Load Testing no tiene por objetivo principal encontrar errores por concurrencia. Cuando varios usuarios llaman a concurrentemente al servidor puede ser que no existan problemas de Performance pero el servidor puede estar realizando acciones equivocadas, por ejemplo, vender el ultimo ítem del inventario a varios usuarios o solamente caer. Por eso, es buena práctica realizar pruebas exploratorias al mismo momento en que se están realizando las pruebas de carga las cuales tendrán por objetivo encontrar este tipo de problemas.

Load testing es una subcategoria de Performance Testing enfocada en determinar o validar la Performance de las caracteristicas de la aplicación bajo prueba cuando la misma es objeto de carga de trabajo simulando el uso que tendra la misma en producción.

Error 4: Confundir el Web Server con la aplicación Web

El servidor Web recibe las peticiones http y rápidamente las traduce en otras clases de peticiones para aplicaciones. La cantidad de tiempo gastado en el servidor Web por si mismo debería ser insignificante (o por lo menos por debajo del milisegundo por petición). Todo el tiempo corresponde a la aplicación  detrás de él.

Además, necesita asegurarse de que la capa del servidor Web pueda manejar el número de conexiones simultáneas requeridas, este numero va aumentando a medida que aumentan los pedidos al servidor, el cliente tiene un pobre ancho de banda, y otras posibilidades….

Pero al final, lo que se intenta testear es lo que esta detrás de la cortina, no la cortina. Esto significa que mientras hacemos Load Testing sobre una aplicación Web, comúnmente no debemos preocuparnos de cosas como: emulando variaciones http, enviando peticiones http a páginas o imágenes estáticas, o cualquier otra cosa que sea manejado por el Web Server y no por la aplicación. Otra cosa con la que no debemos distraernos son aquellas aplicaciones que realizan mediciones sobre el Web Server (MindCraft’s WebStone, SPEC’s specWeb96 o ZDNet’s WebBench) ya que son para testear Web Servers, no Aplicaciones Web.

11 pensamientos en “Errores más comunes al realizar Pruebas de Performance – Parte I”

  1. Primero agradesco por el Blog que contiene mucha información útil.

    En cuanto los errores más comunes, estoy totalmente de acuerdo y me hubiera gustado haber leido esta información antes.

    Muchas Gracias 🙂

    Me gusta

  2. Tu sitio me ha servido mucho, por lo menos para entender el JMeter, pero tengo un problema, cuando arranco la grabacion para el Plan de Pruebas y navego por el aplicativo web sobre el cual quiero hacer las pruebas, solo graba esto

    /free/windows/installer/RealUpgrade/master.xml

    que no tengo idea que es.

    Agradezco si puedes ayudarme, estoy trabajando con JMeter 2.4 y mi aplicativo es en .Net

    Me gusta

    1. Brigitte,

      Deberías verificar si es correcta la configuración del proxy, ya que parece un problema de ese tipo. Ademas, es recomendable tener abierta solo la ventana de tu aplicación.

      Si puedes escribir como configuraste el proxy, podemos ver cual puede ser el problema.

      Saludos,

      José

      Me gusta

      1. Hola gracias por tu pronta respuesta,

        Configure el proxy como
        Address: Localhost y Puerto: 8080

        Es decir paso a paso tal como lo muestras en tu video.

        Me gusta

      2. Brigitte,

        Por lo que me parece que estas haciendo durante tus pruebas, estas corriendo una aplicación en forma local, la cual corre sobre algún puerto de tu maquina. En ese caso el proxy debe estar seteado para capturar el mismo puerto ya que sobre el puerto.

        Ejemplo: Tu aplicación corre sobre http://localhost:8484/miaplicacion.html

        En ese caso el proxy se debería configurar con puerto 8484 en lugar del 8080, ya que el 8080 es para capturar la interacción entre el navegador y la web.

        Saludos,

        José

        Me gusta

      3. Muchisimas gracias por tu ayuda, ya pude iniciar el trabajo con Jmeter.

        Tus publicaciones son muy ùtiles y sobre todo fàciles de entender.

        Saludos,

        Brigitte

        Me gusta

  3. Jose Pablo,

    Estoy realizando un test de prueba bàsico para mi aplicaciòn, me gustarìa saber si conoces algùn sitio o si me puedes colaborar con la interpretaciòn de informes.

    Gracias, Brigitte

    Me gusta

  4. Jose Pablo:
    Muchas gracias de antemano por tus enseñanzas.
    Deseo preguntarte:
    Yo salgo a Internet por un proxy xxx.xxx.xxx:3128
    Como configuro el proxy del Jmeter (Banco de Trabajo –>Elementos No de Prueba –> Servidor proxi HTP) si es que tengo esta configuracion? ya que no utilizo el localhost:8080
    Muchas gracias por tu ayuda de antemano
    Carlos

    Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s