Pruebas de carga y rendimiento en un canal de entrega de DevOps

Las aplicaciones de software modernas deben responder rápidamente a los requisitos comerciales cambiantes, así como corregir rápidamente errores, problemas de rendimiento y problemas de seguridad para seguir siendo competitivos. Sin embargo, en un entorno de desarrollo tradicional, el tiempo que lleva probar exhaustivamente una aplicación de software antes de su lanzamiento entra en conflicto con el ritmo con el que la aplicación necesita evolucionar.

Las metodologías DevOps han demostrado ser efectivas para conciliar estos requisitos contradictorios de lanzar y entregar rápidamente software de alta calidad. Por este motivo, han obtenido una amplia adopción en las organizaciones de desarrollo de software con visión de futuro.

DevOps utiliza ampliamente el concepto de proceso continuo, que se aplica a todas las etapas del ciclo de vida de la aplicación, incluida la modificación del código, las pruebas de la aplicación y el monitoreo de la implementación y la producción. Si bien las prácticas continuas de pruebas unitarias y de integración han obtenido una amplia adopción, pruebas de rendimiento continuas se ha quedado notablemente rezagado, en gran parte debido a la lucha de las organizaciones por integrar las pruebas de rendimiento tradicionalmente manuales en un proceso de DevOps altamente automatizado. En este artículo describiremos cómo las pruebas de rendimiento deben cambiar para convertirse en una parte integral del entorno DevOps.

¿Por qué son vitales las pruebas de rendimiento para las aplicaciones de servidor?

Las aplicaciones pueden fallar de varias maneras. Para detectar errores, el desarrollo de software y el control de calidad emplean múltiples tipos de pruebas. Los más comunes incluyen los siguientes.

• Pruebas unitarias
• Pruebas de integración
• Pruebas de seguridad
• Pruebas de rendimiento
• Pruebas de distribución

Cada uno de estos tipos de pruebas aborda una categoría específica de fallas que una aplicación puede experimentar en producción. Las pruebas de rendimiento, que son el tema de este artículo, se dirigen a un conjunto de tipos de fallas que ocurren cuando la aplicación se somete a una carga de solicitudes simultáneas. A continuación se detallan los seis tipos de fallas más comunes.

1. Tiempos de respuesta lentos. Los tiempos de respuesta caen por debajo del nivel aceptable debido a cuellos de botella en las aplicaciones o la infraestructura.
2. Indisponibilidad parcial. Un estado en el que algunas solicitudes de clientes no reciben respuestas. Esto puede ocurrir debido a asignaciones insuficientes de recursos, fugas de recursos, problemas de concurrencia (condiciones de carrera, puntos muertos), etc.
3. Completa indisponibilidad. Los fallos de las aplicaciones pueden ocurrir cuando los efectos que causan una indisponibilidad parcial se acumulan hasta niveles en los que afectan a toda la aplicación.
4. Respuestas de error. Las respuestas de la aplicación indican que no pudo procesar las solicitudes de los clientes, al devolver, por ejemplo, respuestas HTTP 500. Esto puede deberse a los mismos motivos que provocan la indisponibilidad parcial de la aplicación, pero provocan un comportamiento diferente debido a la lógica de la aplicación.
5. Contenido incorrecto en las respuestas. La aplicación devuelve respuestas bien formadas con contenido incorrecto. Por ejemplo, el contenido incorrecto intermitente en las respuestas puede deberse a condiciones de carrera.
6. Posibles implicaciones de seguridad causadas por problemas de rendimiento. Un ejemplo de esto es no manejar adecuadamente los ataques DOS (denegación de servicio) o revelar detalles internos de la aplicación, lo que puede filtrarse en las respuestas del servidor como descripciones de error cuando la aplicación entra en mal estado debido a una sobrecarga.

Cada una de estas fallas es capaz de causar pérdidas financieras y dañar la reputación de la organización como proveedor de servicios confiable. A continuación, veremos los pasos sobre cómo integrar las pruebas de rendimiento en el proceso de DevOps para detectar estos problemas a tiempo.

Integre las pruebas de rendimiento en la canalización de entrega continua

Puede comenzar a integrar las pruebas de rendimiento en la canalización de entrega continua agregando pruebas de rendimiento seleccionadas a Jenkins, o una herramienta de integración continua de su elección, y haciendo que se ejecuten con regularidad.

Según sus necesidades, puede ejecutar pruebas de rendimiento en uno o más de los siguientes puntos durante la construcción o prueba de la infraestructura.

• Después de cada construcción con un conjunto reducido de pruebas de rendimiento de "humo".
• Una vez al día con un conjunto más completo de pruebas de rendimiento.
• Una vez al fin de semana o según la disponibilidad de la infraestructura con un conjunto de pruebas de larga duración para pruebas de resistencia o pruebas de carga de gran volumen para pruebas de estrés.

Sin embargo, esto por sí solo no es suficiente.

El análisis manual de informes de pruebas de carga puede llevar mucho tiempo y puede requerir habilidades especiales que no todos los desarrolladores poseen. Sin la capacidad de automatizar el análisis de informes de pruebas de carga, revisar los resultados de las pruebas de rendimiento se convierte en una tediosa pérdida de tiempo. También se puede pasar por alto información vital sobre el rendimiento. En tales escenarios, es posible que esté ejecutando pruebas de rendimiento continuamente, pero el beneficio de ellas será limitado.

Automatice la recopilación y el análisis de los resultados de las pruebas de rendimiento

A Obtenga el beneficio completo de las pruebas de rendimiento continuas, debe configurar un mecanismo eficaz para analizar los resultados de las pruebas de rendimiento. Prueba de carga de Parasoft y su LoadTest Continuum, un módulo de Prueba SOA de Parasoft, brindarle herramientas que le ayuden a automatizar la recopilación y el análisis de los resultados de las pruebas de rendimiento y brindarle información sobre el rendimiento de su aplicación.

Cómo configurar su entorno para la ejecución continua de pruebas de rendimiento

Los siguientes pasos le ayudarán a configurar su entorno para una ejecución de pruebas de rendimiento con Parasoft LoadTest y LoadTest Continuum:

1. Revise y configure las métricas de QoS del proyecto LoadTest para la automatización.
2. Implemente y configure LoadTest Continuum para la recopilación de informes de prueba de carga.
3. Configure los proyectos de LoadTest en lotes para su ejecución.
4. Comience a ejecutar lotes de proyectos LoadTest como parte de la integración continua y utilice LoadTest Continuum para revisar y analizar periódicamente los resultados de las pruebas de rendimiento.

Repasemos estos pasos individualmente con más detalle a continuación.

Paso 1: revisar y configurar las métricas de QoS para la automatización

Las métricas de calidad de servicio (QoS) de Parasoft LoadTest son una de las características clave para automatizar el análisis de los resultados de las pruebas de rendimiento. Las métricas de QoS reducen grandes cantidades de datos en un informe de prueba de carga a un conjunto de respuestas de éxito / fracaso sobre el rendimiento de su aplicación. Parasoft LoadTest ofrece un amplio conjunto de métricas de QoS que van desde métricas de umbral listas para usar hasta métricas con secuencias de comandos personalizadas que le permiten utilizar la API de LoadTest para el análisis avanzado de datos de pruebas de carga.

Para preparar sus pruebas de rendimiento para la automatización, debe revisar las métricas de QoS en sus proyectos de LoadTest. Ejecute un proyecto LoadTest y examine el informe: todos los criterios de éxito y fracaso que utilice para analizar manualmente un informe de prueba de carga deben representarse como métricas de QoS. Convierta tantas métricas como pueda en métricas "numéricas". Una métrica numérica de QoS no solo devuelve un resultado de éxito / fracaso, sino que también cuantifica un indicador clave de rendimiento para esa métrica. Por ejemplo, una métrica que valida un umbral de utilización de la CPU también proporcionaría el valor real de la utilización de la CPU como métrica numérica.

Las métricas numéricas se utilizan ampliamente en LoadTest Continuum para trazar el rendimiento de las métricas a lo largo del tiempo:

Una vez que haya configurado las métricas de QoS para su Proyectos de prueba de carga, es hora de configurar LoadTest Continuum para la recopilación y el análisis de datos de rendimiento.

Paso 2: implementar y configurar LoadTest Continuum

Implemente y configure el archivo de aplicación web LoadTest Continuum ltc.war (disponible en el directorio de instalación SOAtest / LoadTest a partir de la versión 9.10.2), como se describe en la sección “LoadTest Continuum” de la documentación de LoadTest.

Paso 3: configure los proyectos de prueba de carga en lotes para su ejecución

Combine sus proyectos LoadTest en scripts .cmd para la ejecución por lotes. Los scripts LoadTest .cmd son la forma de especificar grupos de proyectos que compondrán diferentes conjuntos de pruebas de rendimiento, como las pruebas de "humo", las pruebas diarias o las pruebas de fin de semana mencionadas anteriormente.

Configure los scripts .cmd para enviar datos de informes a LoadTest Continuum como se describe en la sección "Envío de informes a LoadTest Continuum" de la documentación de LoadTest. Configure su herramienta de integración continua para ejecutar scripts LoadTest .cmd como parte de un proceso de compilación o en intervalos regulares. Por ejemplo, en Jenkins puede ejecutar un script LoadTest .cmd usando el paso de compilación Ejecutar el comando por lotes de Windows de la siguiente manera:

% SOATEST_HOME% \ lt.exe ”-J-Xmx4096M -cmd -run“% WORKSPACE% \ ltcontinuum.cmd

Paso 4: configure un tablero en Parasoft DTP

DTP de Parasoft contiene paneles de informes y análisis que le permiten monitorear el estado y el progreso de su proyecto de software con una variedad de widgets e informes.

Un continuo de pruebas de carga de Parasoft Widget de DTP le permite agregar el resumen de resultados de LoadTest más reciente al panel de su proyecto DTP y ofrece una manera rápida de evaluar el estado de los resultados de las pruebas de rendimiento en su rutina diaria de revisión del estado del proyecto.

El widget muestra el número de pruebas y métricas totales, aprobadas y fallidas de las ejecuciones de LoadTest más recientes. Para ver los resultados con más detalle, haga clic en el enlace del proyecto en el widget y la página LoadTest Continuum se abrirá en una nueva pestaña.

Para configurar un widget HTML personalizado LoadTest Continuum en DTP, simplemente siga estos pasos:

1. En el Centro de informes de Parasoft DTP, cree un nuevo Panel de control o abra uno existente.
2. Presione Agregar widget. En el cuadro de diálogo Agregar widget, seleccione Personalizado -> Widget HTML personalizado.
3. Copie el contenido del siguiente archivo de la instalación de LoadTest Continuum en el área de texto HTML del cuadro de diálogo:% TOMCAT_HOME% \ webapps \ ltc \ dtp \ ltc_dtp_widget.html
4. Modifique el HTML con su configuración personalizada:
   1. Busque la función getServerURL (). Modifique el valor de retorno con el host y el puerto de su instalación de LoadTest Continuum.
   2. Busque la función getProjectName (). Modifique el valor de retorno con el nombre del proyecto que le gustaría rastrear en el widget.
5. Presione Crear.

Paso 5: revise y analice los resultados de las pruebas de rendimiento

Parasoft LoadTest Continuum sirve como punto de recopilación para sus informes de LoadTest y como herramienta de análisis que organiza los datos de las pruebas de carga de múltiples ejecuciones. LoadTest Continuum organiza los datos en una pirámide de información que le permite revisar los resultados de sus pruebas de rendimiento en varios niveles de detalle, desde resúmenes diarios de alto nivel en la parte superior, hasta resultados de métricas de QoS en el núcleo, hasta informes detallados de pruebas de carga en el fondo:

Considere el siguiente flujo de trabajo como un ejemplo de una revisión de prueba regular (diaria):

1. Para pruebas fallidas, siga los siguientes pasos:
   1. Abra la vista Historial de pruebas, compruebe si la prueba ha fallado con regularidad o esporádicamente. El primer caso probablemente indicaría una regresión; el segundo caso una inestabilidad.
   2. Inspeccione las métricas fallidas de la prueba:
      1. Para una métrica numérica, abra la vista de gráfico de historial de métricas. Utilice el gráfico del historial de métricas para obtener información. Por ejemplo, si una prueba a la que pertenece la métrica es inestable, las pequeñas fluctuaciones del gráfico métrico suelen indicar que el umbral de la métrica necesita un ajuste. Las grandes fluctuaciones indican problemas en el código o la infraestructura.
      2. Abra el enlace Todos los gráficos de esta prueba. Verifique los gráficos de otras métricas numéricas para la misma prueba para ver si hay fluctuaciones que no cruzaron el umbral de la métrica.
2. Si no ha configurado los widgets de LoadTest Continuum DTP, comience verificando los resúmenes de éxito / fracaso de las pruebas y métricas en la página principal del proyecto LTC.
3. Para proyectos que tienen fallas, siga el enlace a la página del proyecto LTC para examinar los detalles.
4. Comience verificando el estado de sus ejecuciones de prueba de carga más recientes en los widgets LoadTest Continuum DTP.
5. Haga lo mismo con el enlace Todos los gráficos de esta métrica para comprobar si se vieron afectadas métricas similares de otras pruebas. En caso afirmativo, esto indica un problema sistémico con su aplicación o infraestructura que no se limita a una sola prueba (consulte la Fig. 4).
6. Para un análisis más profundo, abra los informes HTML o binarios de prueba de carga de la prueba fallida.

La integración de un proceso de prueba de rendimiento en la tubería de entrega continua es esencial para garantizar la calidad del software. Para aprovechar al máximo este proceso, debe configurar un mecanismo eficaz para la automatización del análisis de los resultados de las pruebas de rendimiento.

Sea continuo con Parasoft

Logre todos sus elevados objetivos de automatización del análisis de resultados de pruebas con Parasoft LoadTest y LoadTest Continuum dentro de Parasoft Prueba SOA. Estas herramientas ofrecen una automatización sofisticada dentro de las pruebas funcionales, para que pueda ofrecer software de mayor calidad.