¡Descubra las novedades de MISRA C:2012 AMD3 y cómo obtener la cobertura MÁS AMPLIA con C/C++test 2022.2! Ver a pedido >>

Conquiste los desafíos de las pruebas de rendimiento

Por Serguéi Baranov

15 de diciembre de 2022

5  min leer

Las pruebas de rendimiento le indican cómo se comportará su aplicación cuando se exponga al mundo real y se someta a un flujo de solicitudes de los usuarios. Obtenga métodos y estrategias de prueba de rendimiento para preparar su aplicación de manera eficiente y confiable para que coincida con las cargas de trabajo de producción y garantizar su éxito.

Las organizaciones de desarrollo de software están bajo presión para proporcionar una excelente experiencia de usuario mientras equilibra los costos de desarrollo y mantenimiento. Para una aplicación de software de servidor, como una aplicación web o una API, las respuestas consistentemente rápidas y confiables son tan importantes como la corrección funcional para garantizar la satisfacción del usuario y el éxito de la aplicación.

Pruebas de rendimiento es el área de aseguramiento de la calidad del software que se enfoca en la capacidad de respuesta y confiabilidad de una aplicación cuando está sujeta a un flujo de solicitudes de múltiples usuarios. Eso evalúa cómo se comporta una aplicación bajo la solicitud de servicio esperada carga y analiza los resultados para que se puedan identificar y resolver los cuellos de botella y otras ineficiencias que impiden el funcionamiento sin problemas bajo carga.

  • Las herramientas de prueba de rendimiento pueden ayudar a garantizar que su sistema manejará:
  • Carga regular de solicitudes de servicio y
  • Variaciones en los tipos de solicitudes y patrones de tráfico.

Sin embargo, incluso las mejores herramientas no son suficientes si no se aplican en el contexto de la práctica y la estrategia de pruebas de rendimiento correctas. Sólo la combinación de los dos puede asegurar el éxito.

Problemas del enfoque tradicional

Las pruebas de rendimiento se han basado tradicionalmente en una aplicación casi funcional que se ejecuta en un entorno de producción o preproducción. Por implicación, esto es tarde en el ciclo de vida de desarrollo para descubrir problemas importantes. Los problemas encontrados tan tarde tienen un gran impacto en el costo y el cronograma.

Además, el tiempo y el esfuerzo necesarios para completar el ciclo completo de pruebas de rendimiento manuales limita la frecuencia con la que se puede realizar, lo que limita la frecuencia de los ciclos de lanzamiento o hace que las organizaciones realicen lanzamientos con pruebas de rendimiento parciales o sin ellas.

La búsqueda de soluciones que redujeran la incertidumbre y el riesgo causados ​​por los problemas descritos anteriormente empujó a las organizaciones a comenzar a aplicar pruebas de rendimiento a las estrategias ágiles y de cambio a la izquierda que ya se usaban y demostraban ser efectivas en otras áreas de pruebas de software.

Desafíos de las pruebas de rendimiento modernas

La prueba de rendimiento con desplazamiento a la izquierda establece que los problemas del enfoque tradicional provienen de probar demasiado tarde y con poca frecuencia. Por lo tanto, debe probar temprano y con frecuencia.

Esto suena bien en teoría, pero ¿cómo se implementa en la práctica?

Para que las promesas de la prueba shift-left se materialicen, debe resolver el siguiente conjunto de problemas:

  • ¿Cómo probar el rendimiento de una aplicación que aún no existe?
  • ¿Cómo encontrar el equilibrio entre agilidad y costes?
  • ¿Cómo hacer que la automatización de las pruebas de rendimiento valga la pena?
  • ¿Cómo reducir los costos de instalación y operación?

Problema 1: ¿Cómo probar el rendimiento de una aplicación que aún no existe?

El requisito de comenzar temprano significa que las pruebas de rendimiento deben crearse junto con las pruebas unitarias y funcionales, lo que puede llevar mucho tiempo antes de que la aplicación final tome forma. Estos dos métodos principales le permiten comenzar a probar el rendimiento de una aplicación de servidor antes de que sea completamente funcional.

  • Virtualización de servicios
  • Pruebas de rendimiento a nivel de unidad

La virtualización de servicios permite probar aplicaciones de forma temprana al emular el comportamiento de sus dependencias externas, como API, bases de datos, sistemas de mensajería y más, que pueden no estar disponibles en las etapas iniciales de desarrollo por una de las siguientes razones:

  1. Se están trabajando en paralelo con la aplicación bajo prueba (AUT).
  2. El acceso a ellos es limitado.

Una herramienta de virtualización de servicios debería permitirle imitar las respuestas de las dependencias externas y sus parámetros de rendimiento, como los retrasos en las respuestas, que afectarán el rendimiento de la AUT de forma realista.

Las pruebas de rendimiento a nivel de unidad le permiten evaluar componentes internos y de terceros que planea integrar en su aplicación. Por ejemplo, puede evaluar el rendimiento de bibliotecas de analizadores JSON alternativas para los tamaños de solicitud y los niveles de carga que espera de su aplicación de destino. Esto le ayudará a elegir la mejor alternativa y establecer expectativas de rendimiento realistas para su aplicación en función del rendimiento de los componentes que utiliza.

Problema 2: Agilidad vs Costos. ¿Cómo encontrar el equilibrio?

El requisito de probar con frecuencia puede sugerir que las pruebas de rendimiento deben ejecutarse con la misma frecuencia que las pruebas unitarias o funcionales en un proceso de compilación de integración continua (CI) desencadenado por revisiones de código fuente.

Si bien las pruebas de rendimiento deben ser una parte integral de la entrega continua de aplicaciones, la aplicación de la misma lógica de frecuencia de prueba que funciona para las pruebas unitarias o funcionales puede no ser práctica porque ejecutar el conjunto completo de pruebas de rendimiento generalmente requiere mucho más tiempo y recursos informáticos.

Para resolver este problema, el conjunto de pruebas de rendimiento de la aplicación debe constar de diferentes tipos de pruebas de rendimiento, cuya frecuencia de ejecución sea inversamente proporcional al tiempo y los recursos necesarios para ejecutar estas pruebas. Con este enfoque, se pueden ejecutar pruebas de rendimiento de línea de base o humo relativamente cortas como parte del proceso de creación de CI, mientras que las pruebas más completas se ejecutan regularmente, pero con menos frecuencia.

Frecuencia de prueba Tipo de prueba
Cada compilación de CIPrueba de humo/línea de base, pruebas de rendimiento de la unidad
Diario/NocturnoPrueba de carga media
Una vez a la semanaPrueba de resistencia, prueba de esfuerzo

Problema 3: ¿Cómo hacer que la automatización de pruebas de rendimiento valga la pena?

La ejecución automatizada de las pruebas de rendimiento por sí sola tendrá poco valor sin la automatización del análisis de los resultados de las pruebas. Una prueba de rendimiento puede generar una gran cantidad de datos. A medida que avance el desarrollo de la aplicación, crecerá el número de pruebas de rendimiento, la complejidad de sus escenarios y su duración. La ejecución continua de estas pruebas crea una gran cantidad de datos que deben reducirse a una respuesta de aprobación/rechazo. Esta respuesta generalmente surge como resultado de las verificaciones del acuerdo de nivel de servicio (SLA) que se aplican automáticamente a los datos de prueba de rendimiento recopilados al finalizar la prueba.

La creación de un conjunto completo de comprobaciones de SLA estables para cada prueba de rendimiento es clave para una automatización exitosa de las pruebas de rendimiento.

Indicador clave de rendimiento (KPI)Criterios de aceptación de SLA
Tiempo promedio de respuestaDebe ser menos de 1 segundo
Tasa de fracasoDebe ser inferior al 0.01%

Para obtener todos los beneficios de la ejecución continua de pruebas, los resultados de las pruebas de rendimiento deben publicarse automáticamente en un panel de informes y análisis para que pueda comprender rápidamente los datos de tendencias. El enfoque de desplazamiento a la izquierda agrega desarrolladores como usuarios del tablero, además de gerentes y evaluadores. Por lo tanto, el tablero debe tener los detalles de bajo nivel que los desarrolladores buscan para investigar y establecer de manera efectiva las causas de las fallas de SLA o las tendencias históricas.

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

La automatización de pruebas no tiene que detenerse en la etapa de ejecución de pruebas de rendimiento y análisis de aprobación/falla. El siguiente nivel es análisis de causa raíz automatizado de pruebas de rendimiento.

4. ¿Cómo reducir los costos operativos y de instalación?

Los beneficios de las pruebas de rendimiento automatizadas con desplazamiento a la izquierda tienen el costo de construir la infraestructura de automatización de pruebas, crear o modificar pruebas y, potencialmente, adquirir y aprender nuevas herramientas y cambios culturales.

En este viaje, debe asegurarse de que las herramientas de prueba de rendimiento que utiliza se ajusten a los nuevos principios que está poniendo en práctica. A continuación se muestra una lista de las funciones de la herramienta de prueba de rendimiento que le ahorrarán tiempo en la configuración y el mantenimiento de las pruebas automatizadas.

  • Ofrece una amplia interfaz de línea de comandos para la ejecución automatizada de pruebas de rendimiento.
  • Permite la reutilización de recursos de prueba, como activos de prueba funcional, monitores de rendimiento, comprobaciones de SLA, etc.
  • Se puede utilizar en entornos informáticos cerrados y en la nube.
  • Proporciona funcionalidad para actualizaciones masivas de proyectos de prueba de rendimiento.
  • Admite la generación automatizada de casos de prueba.
  • Admite el análisis automatizado de la causa raíz de la falla.
  • Hace que las cosas comunes sean fáciles y las cosas avanzadas posibles.

En la práctica, esto significa que mientras ofrece GUI para tareas comunes de prueba de rendimiento, la herramienta ofrece una opción para ampliar su funcionalidad con secuencias de comandos en todas las áreas funcionales principales. Una interfaz GUI para tareas comunes proporcionará productividad y una rápida curva de aprendizaje, mientras que la extensibilidad con secuencias de comandos o programación asegurará que, independientemente de cuán específicos sean sus requisitos de pruebas automatizadas, la herramienta debe proporcionar los medios para cumplirlos.

La estabilidad y la mantenibilidad de las pruebas contribuyen en gran medida a reducir los costos operativos de las pruebas de rendimiento. Si bien este tema merece un artículo aparte, mencionaremos un área que a menudo se pasa por alto si se analizan las pruebas de rendimiento de las aplicaciones web desde una perspectiva tradicional. Las aplicaciones web modernas usan llamadas API en gran medida, la tendencia es usar llamadas API exclusivamente para obtener contenido dinámico de los servidores.

Esta creciente dependencia de las aplicaciones web en las llamadas API impulsa un cambio cualitativo en las pruebas de rendimiento modernas. Cuando el contenido estático de una aplicación web es atendido por redes de entrega de contenido (CDN) de alta disponibilidad, la mayor parte del tiempo de carga de la página web proviene de las llamadas a la API. El rendimiento de tales aplicaciones web se convierte en una función del rendimiento de las API de las que depende, lo que justifica el reemplazo de la interfaz de usuario con pruebas de rendimiento de API.

Tal reemplazo trae múltiples ventajas.

  • Pruebas API más estables
  • Se requieren significativamente menos recursos informáticos para ejecutar
  • Fácil de reutilizar a partir de pruebas funcionales existentes

Reemplazar la interfaz de usuario con pruebas de rendimiento de API para calificar aplicaciones web puede contribuir en gran medida a la estabilidad de su prueba de rendimiento y reducir los costos operativos.

A dónde ir a continuación

Las pruebas de rendimiento modernas introducen nuevos principios impulsados ​​por la automatización de pruebas. Las ineficiencias del proceso de prueba tradicional se descartan, pero los cimientos permanecen. Y es importante revisar y aplicar de manera eficiente las nuevas prácticas.

Guía de mejores prácticas de pruebas de rendimiento

Por Serguéi Baranov

Sergei es un ingeniero de software principal en Parasoft, y se centra en las pruebas de carga y rendimiento dentro de Parasoft SOAtest.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.