El "Tester del Futuro"

Actualmente nos encontramos ante un desarrollo tecnológico que está dando lugar a nuevos entornos y necesidades. Algunos ejemplos son:

• La proliferación de dispositivos móviles hace que al día se realicen millones de descargas de apps. Las apps para dispositivos móviles integran distintas tecnologías y a su vez pueden hacer uso de aplicaciones de terceros
• El Cloud Computing está tomando una gran relevancia debido a las facilidades que ofrece para que cualquier empresa pueda utilizar aplicaciones en Cloud de manera barata y accesible.
• Las aplicaciones son cada vez más complejas e integran componentes de distintas tecnologías y proveedores.

El testing, como cualquier otra actividad del desarrollo e implantación de los S.I., se ha adaptado a este nuevo entorno: herramientas, metodología, tecnología, etc...

El ingeniero de pruebas se ha renovado y adaptado a los cambios. Pero, ¿cuáles son las características del tester del futuro?, ¿y qué conocimientos debe tener?

Intentaremos enumerar algunos de los desafíos a los que se enfrentan los ingenieros de pruebas en el actual contexto tecnológico, pero... el futuro ya está aquí!!

SOAP UI y JMeter. Colaboraciones

En esta entrega, vamos a hacer un post absolutamente oportunista, combinando dos de las herramientas de prestaciones y calidad quizás más conocidas por los usuarios de este mundillo.
SOAP UI realiza pruebas sobre servicios web. Aunque ya se explicó en otro artículo, daremos unos breves apuntes sobre cómo acceder a un servicio publicado para realizar una grabación del mismo y combinarlo con la herramienta JMeter, para obtener un sistema de pruebas sobre dichos webservices. De esta forma combinaremos las capacidades de manejo de los WDSL de SOAP con las utilidades de análisis y las capacidades de monitorización (a través de los plug-ins) que permite JMeter.

Grabando un webservice. Conceptos y definición

En la pantalla de inicio de SOAP UI, podemos ver la invocación a un WDSL cualquiera  de ejemplo

• Diferentes métodos WDSL - XML descriptivo.
• Validación del WDSL.

Pruebas de rendimiento en Producción

1. ¿Pruebas en Producción?

Los entornos diseñados para pruebas presentan limitaciones a la hora de realizar pruebas de rendimiento:

• Los entornos de pruebas son de capacidad inferior a los entornos productivos. Se han diseñado esencialmente para realizar pruebas funcionales y para soportar niveles de concurrencias inferiores a las de producción.

• No son idénticos. El entorno de pruebas y el entorno de produción están configurados por elementos diferentes:
• Elementos de red: firewalls, encriptadores, balanceadores
• Sistemas Operativos diferentes.
• Configuraciones diferentes en los servidores.

• Generalmente, el volumen de datos almacenados es inferior en los entornos de pruebas.

Estas limitaciones implican que los resultados de las pruebas de rendimiento obtenidos en los entornos de pruebas no son extensibles a los entornos de producción. Más allá de que los tiempos de respuesta estén relacionado con la capacidad de las máquinas, en general, el comportamiento de un sistema o aplicación depende de la configuración y carácterísticas de los recursos. Todos hemos oído frases como "en el entorno de pruebas no conseguimos reproducir el error que se está dando en producción", o "en producción ese error no se va a dar porque la configuración es diferente".

Una posible solución, más usada de lo que a podría caber esperar, es realizar las pruebas de rendimiento directamente sobre el entorno de producción para garantizar que los resultados obtenidos y el comportamiento del sistema bajo pruebas sea similar al que los usuarios se van a encontrar una situación real.

 

2. Condicionantes de las pruebas en Producción

A la hora de diseñar y ejecutar pruebas de rendimiento en entorno productivos, debemos tener en cuenta algunos condicionantes y carácterísticas. Veamos algunos de ellos:

• Datos de prueba:
• En Producción, las pruebas se realizan sobre datos reales. El uso de usuarios, passwords u otros datos de prueba puedeestar sujetos a clausulas de confidencialidad.

• Ciclos de pruebas/modificación de datos: 
• Por defecto, los ciclos de prueba actúan sobre datos reales. Las actuaciones sobre los datos quedarán realizadas de manera real: Altas, Bajas, modificaciones, etc.. se realizan sobre datos reales.

• Inyección de carga:
• Tenemos que asegurarnos que nuestros inyectores de carga "atacan" a la aplicación a través de los mismos componentes que los usuarios reales. La situación habitual en la que los inyectores de carga se encuentran sobre la misma red que los servidores de la aplicación, puede implicar que las peticiones se salten ciertos elementos de red como firewalls, encriptadores, etc... que sí se encuentran los usuarios reales. 

• Intrusividad:
• Las pruebas sobre entornos productivos son intrusivas para los usuarios reales. Por ejemplo, pueden introducir retardos, sobresaturar elementos de la red etc...

Podemos aplicar distintas soluciones para solventar estos condicionantes. Entre ellos podemos citar la creación de datos ficticios dentro de la producción, conmuntar el entorno a una base de datos ficticia para su uso únicamente durante las pruebas, o la posibilidad de recurrir al cloud testing para la inyección de carga desde áreas geográficas externas a la red corporativa.

Para el disño de las pruebas en producción podemos realizar  un mapa menata en el que escribamos cada una de las fases y las posibles condicionantes o riesgos. Un ejemplo es el siguiente:

"Click" para aumentar la imagen

Think Time y Pruebas de Rendimiento

Definición:

En el ámbito de las pruebas de rendimiento, se define el Think Time o Tiempo de espera como el intervalo de tiempo que simula los instantes en los cuales un usuario de la aplicación está ocupado en realizar tareas de manera local.

• Ejemplos:
  
  

  
  • Un lector de un periódico on-line se encuentra leyendo una noticia.

• Un operador de un call-center cumplimenta los campos de un formulario con los datos que le indica un cliente que se encuentra al teléfono.

  
  
  
  
  

Criterio de calidad de las pruebas de prestaciones. Una aproximación

Introducción

Como bien sabe todo aquel que haya presentado en alguna ocasión un informe de pruebas de rendimiento, presenta de manera periódica la típica frase del solicitante de las pruebas:

“Si, el informe muy bien, los gráficos muy bonitos y demás, pero ¿cómo va la aplicación:mejor o peor ,bien o mal…?”

Habitualmente nuestra respuesta se basa en disponer de datos previos al lanzamiento de las pruebas, bien sea por criterios de rangos de rendimiento establecidos por los solicitantes de las pruebas (“se deben alcanzar las 300 transacciones por hora, con una concurrencia de 15 usuarios”) o si se trata de pruebas sobre aplicaciones con versiones en Producción, sacar datos de rendimiento históricos y extrapolarlos.

Sin embargo, muchas veces nos encontramos con la falta de este tipo de información y es cuando surge la pregunta ¿va bien o mal?

Proponemos un criterio que mezcle la subjetividad con los datos que podemos obtener de la prueba. El dato en el que nos podemos basar es el del tiempo en vacio.

Desarrollando el modelo.

Recordemos que esta métrica indica lo que tardaría un usuario sin concurrencia en realizar una navegación o ciclo de prueba. Si tomamos ese dato podemos extrapolarlo al número de operaciones que se pueden ejecutar a la hora. Una manera de establecer el criterio de calidad sería

“Si el usuario tarda 10 segundos en realizar una navegación completa, hará 360 transacciones a la hora”.

Si incrementamos el número de “N” usuarios virtuales/unidades de inyección de carga a lo largo de la prueba, en el punto de saturación debería hacer

Rendimiento teórico=N * transacciones/hora usuario virtual en vacio

Tabla 1. Fórmula del rendimiento máximo teórico del modelo

Como realmente lo que se obtiene en el punto de saturación son “M” transacciones por hora, un criterio de calidad fácil sería

Rendimiento real M / Rendimiento teórico N

Tabla 2. Cálculo del porcentaje de calidad real respecto del máximo teórico

expresado en forma de porcentaje.