Pruebas de rendimiento en SAP: carga, concurrencia y herramientas

Las pruebas de rendimiento en SAP demuestran, antes del go-live, que las transacciones críticas, los jobs en segundo plano y las interfaces cumplen los tiempos de respuesta acordados cuando muchos usuarios y jobs se ejecutan a la vez. En mi experiencia, las pruebas que importan son las de concurrencia, ejecutadas con datos enmascarados a volumen de producción y frente a criterios de superado y fallido que el negocio acordó antes de la primera ejecución.

Esta guía está dirigida a CIO, directores de programa y líderes de pruebas en programas S/4HANA, incluido RISE with SAP. Trata qué probar, qué datos necesita, cómo redactar los criterios de aceptación, qué herramientas hacen el trabajo y quién es responsable de qué. Para ver dónde se ubica el rendimiento entre los demás tipos de prueba, empiece por mi visión general de las pruebas SAP explicadas.

Los problemas de rendimiento en los programas SAP rara vez son una sorpresa.

Los tiles de Fiori agotan el tiempo de espera cuando cientos de usuarios inician sesión al comienzo de un turno. Un informe a medida se congela porque alguien lanzó una selección de ejercicio fiscal sin límites contra una tabla muy grande. Los jobs en segundo plano se solapan en el cierre mensual y la ejecución de contabilización se cancela.

Todo esto es previsible. La única pregunta es si el programa lo probó o si el negocio lo descubre con pedidos reales en marcha.

Pruebas de rendimiento a lo largo de SAP Activate

1. 01

   Explore

   Identifique los riesgos de rendimiento en el diseño. La arquitectura y la forma de los informes deciden los resultados antes de escribir código.

2. 02

   Realize

   Ejecute pruebas de volumen y de carga a medida que la configuración se estabiliza. Una configuración parcial produce resultados engañosos.

3. 03

   Antes de la UAT

   Complete el ciclo completo de rendimiento antes de la UAT, no como parte de ella.

4. 04

   Cutover

   Apruebe el cutover frente a los criterios de aceptación acordados de antemano, no frente a opiniones.

5. 05

   Hypercare

   Vigile los KPI en vivo durante 30 a 60 días. La mayoría de las regresiones aparecen en el primer ciclo de cierre.

En un sistema ECC sobre una base de datos tradicional, las pruebas de rendimiento consistían en someter a carga el servidor de aplicaciones y la base de datos: el tiempo de ejecución ABAP, el rendimiento SQL y la planificación de jobs. El front end era SAP GUI, que rara vez sorprendía a nadie.

En S/4HANA, con front ends Fiori, extensiones en SAP BTP e integración mediante SAP Cloud Integration, el rendimiento depende de varias capas a la vez. Un tile de Fiori lento puede ser una llamada ABAP larga, un timeout del gateway, un servicio OData no diseñado para peticiones concurrentes o la latencia de red en una configuración híbrida. Probar solo el back end no lo encontrará.

1. 01Lanzamiento del tileAvalanchas de inicios de sesión al comienzo del turno
2. 02Llamada ODataTimeouts del gateway, servicios no diseñados para la concurrencia
3. 03Procesamiento ABAPLlamadas ABAP de larga duración
4. 04Lectura de base de datosSelecciones sin límites en tablas grandes
5. 05RenderizadoMás la latencia de red de las sedes lejanas

Un solo tiempo de respuesta, medido de principio a fin

Las pruebas de rendimiento de SAP HANA tienen su propio matiz en una conversión. El código estable de ECC se comporta de forma distinta en una base de datos en memoria. Muchos programas se vuelven mucho más rápidos, mientras que otros producen perfiles inesperados con determinados patrones de datos, así que la regresión específica de la conversión para el código a medida más pesado no es opcional.

Los flujos de integración añaden su propio riesgo. Flujos que funcionaban en desarrollo con mensajes de prueba sueltos pueden acumularse en cola o fallar sin aviso con volúmenes de producción. Los síntomas parecen otra cosa: fallos intermitentes de pedidos, discrepancias en facturas, datos presentes en un sistema y ausentes en otro.

Las pruebas de rendimiento deben hacerse antes del go-live. Las que considero importantes son las de concurrencia: muchos usuarios y jobs usando las mismas transacciones, tablas y servicios al mismo tiempo.

Que un solo usuario cree un pedido de cliente en dos segundos no demuestra casi nada. El mismo pedido con 150 personas introduciendo pedidos, una ejecución de entregas en segundo plano y una interfaz contabilizando mensajes entrantes es la prueba que predice el primer día.

Esta tabla muestra qué demuestra cada tipo de prueba y cuándo ejecutarla:

Prueba	Qué demuestra	Cuándo ejecutarla	Qué suele encontrar
Concurrencia	Muchos usuarios y jobs pueden trabajar a la vez sobre los mismos objetos	Realize, una vez que la configuración es estable, y otra vez antes de la UAT	Esperas por bloqueos, avalanchas de inicios de sesión, cuellos de botella en el gateway
Carga	El sistema cumple los tiempos de respuesta con el volumen pico previsto	Realize, cuando los guiones de concurrencia funcionan	Servicios OData lentos, informes a medida pesados
Estrés	Dónde se rompe el sistema por encima de los límites de diseño	Antes de la UAT, si se prevé crecimiento	Huecos de dimensionamiento, límites de colas
Resistencia	El sistema mantiene una carga estable durante horas	Antes de la UAT, idealmente a lo largo de un cierre simulado	Crecimiento de memoria, contención entre cadenas de jobs en ejecuciones repetidas
De principio a fin	El camino completo que espera un usuario cumple el objetivo	Junto a las pruebas de carga	Problemas invisibles cuando cada capa se prueba por separado

La palabra clave en las pruebas de carga es previsto. Necesita volúmenes de transacciones, números de usuarios y patrones de sesión reales. Una prueba de carga construida sobre estimaciones de volumen que todos sabían optimistas da un aprobado que no significa nada.

La prueba de resistencia es la que más a menudo se omite. Las pruebas de volumen en general son el atajo que los programas toman con más frecuencia cuando se comprime el calendario, y del que más se arrepienten.

Prepare primero estos guiones. Cubren la mayoría de los fallos que llegan a producción.

1. Cambio de turno y pico de inicios de sesión. Cuando unos cientos de usuarios abren el launchpad de Fiori al mismo tiempo, la autenticación y la carga del launchpad se disparan. Un sistema que va bien fuera del pico puede ser inutilizable en esa ventana si nunca se probaron los inicios de sesión concurrentes.
2. Cierre mensual y anual. Contabilizaciones de gran volumen, cadenas de jobs con una secuencia estricta y un equipo de finanzas contra una fecha límite fija. Ejecute las cadenas de jobs del cierre de principio a fin con los volúmenes del periodo de cierre, no con los recuentos diarios medios.
3. Jobs en segundo plano que se solapan. Los jobs batch suelen probarse de uno en uno, lo que no refleja la realidad. Un job mal optimizado puede bloquear a varios otros, y el cierre se sale de su ventana.
4. Informes a medida sin límites. Un informe que responde al instante con datos de prueba puede tardar minutos con un ejercicio fiscal completo. Pruebe las selecciones típicas y las del peor caso, y bloquee las que no tienen límites.
5. Usuarios en varias regiones. La latencia de red afecta a cada transacción. RISE traslada el alojamiento a SAP, pero la latencia sigue dependiendo de la región que elija y del enrutamiento hasta sus usuarios, así que pruebe desde las sedes más lejanas.

Mi guía de migración de ECC a S/4HANA explica dónde encajan las pruebas de la conversión en el plan general.

Datos de prueba a nivel de producción

Los datos deciden si algo de esto tiene sentido. Insisto en datos enmascarados a nivel de producción: volumen y realismo de producción, con los campos personales y sensibles enmascarados.

Un cliente con 200.000 líneas de pedido abiertas se comporta de forma distinta a uno con 5.000. Los filtros que responden al instante en un mandante de pruebas con pocos datos agotan el tiempo de espera en producción. Genere volumen en las áreas de alto riesgo, use una combinación de transacciones representativa y haga llamadas reales a las interfaces donde pueda.

Cómo obtener esos datos de forma segura, mediante copias, herramientas de datos de prueba selectivos y enmascaramiento, se explica en mi guía de gestión de datos de prueba en SAP. Planifique el refresco antes del primer ciclo de rendimiento, porque lleva más tiempo del que suponen la mayoría de los planes de prueba.

Acuerde los criterios con el negocio en la fase Prepare, antes de ejecutar ninguna prueba. Cada uno nombra la transacción o el job, la carga y el umbral.

Estos ejemplos muestran la forma. Fije sus propias cifras a partir de las necesidades operativas:

Elemento	Condición de carga	Umbral de superación	Responsable
Creación de pedidos de cliente (VA01 o app Fiori)	150 usuarios concurrentes introduciendo pedidos	Menos de 3 segundos en el 95 % de las transacciones	Responsable del proceso order-to-cash
Primera carga del launchpad de Fiori al comienzo del turno	Pico de inicios de sesión concurrentes del turno más grande	Menos de 5 segundos para el 95 % de los usuarios	Líder de operaciones de TI
Cadena de jobs del cierre mensual	Volúmenes del periodo de cierre, secuencia completa	Termina dentro de la ventana de cierre acordada, sin cancelaciones	Controller financiero
Interfaz de pedidos entrantes	Volumen pico de mensajes por hora	Ningún mensaje en cola con más de 15 minutos de antigüedad	Líder de integración
Informe a medida de gran volumen	Volumen completo de datos de producción, selección típica	Menos de 60 segundos; selecciones sin límites bloqueadas	Responsable del informe

«El sistema debe ser lo bastante rápido para las operaciones del negocio» no se puede probar ni aceptar. Cambiar los criterios después de que lleguen los resultados anula el sentido de tenerlos.

Si el sistema se aprobó porque los usuarios de la UAT dijeron que parecía rápido, tiene una opinión, no un criterio de aceptación. Convierta los resultados en una puerta formal antes del cutover, tal como describe mi guía de quality gates en SAP. El plan general de ciclos, con criterios de entrada y salida para cada fase de prueba, corresponde a su estrategia de pruebas de S/4HANA.

Herramientas de pruebas de rendimiento en SAP

Una prueba de rendimiento necesita tres cosas: un generador de carga capaz de manejar los protocolos de SAP, monitorización del lado de SAP y un lugar para gestionar los casos de prueba y los resultados. LoadRunner es la herramienta de carga que mis equipos han usado en programas SAP. Nombre la herramienta pronto en el plan de pruebas, porque las licencias, los generadores de carga y las habilidades de scripting llevan tiempo.

Las principales opciones en 2026:

Herramienta	Función	Qué conviene saber
OpenText Professional Performance Engineering	Generación de carga	El producto que antes se llamaba LoadRunner Professional. Sus paquetes de protocolos cubren SAP, SAP GUI y SAP Web
Tricentis NeoLoad	Generación de carga	Tricentis indica soporte para SAP GUI, Fiori, RFC e IDoc, y puede reutilizar activos de Tricentis Tosca
Apache JMeter	Generación de carga	Código abierto. Genera tráfico HTTP, como llamadas Fiori y OData
SAP Cloud ALM	Gestión de pruebas	Prepara y ejecuta casos de prueba manuales y automatizados y hace seguimiento de los defectos. No genera carga por sí mismo
SAP Solution Manager	Gestión de pruebas	El mantenimiento estándar termina el 31 de diciembre de 2027, así que planifique el trabajo nuevo en Cloud ALM

Para una visión más amplia de las herramientas funcionales y de automatización, consulte mi comparación de herramientas de pruebas y validación de SAP. La herramienta importa menos que los guiones, los datos y los criterios.

RISE with SAP reparte la responsabilidad

Con RISE with SAP, SAP es responsable de la infraestructura: el dimensionamiento, la región del hiperescalador, la red y la disponibilidad de la plataforma. El cliente y el socio son responsables de la capa de aplicación.

El documento de roles y responsabilidades de RISE de SAP lo dice claramente. La ejecución de las pruebas de carga y el ajuste de las sentencias SQL costosas son SAP Cloud Application Services con cargo adicional. Si no los compra, el trabajo lo hace el cliente.

Un fallo habitual en los programas RISE es suponer que SAP detectará los problemas de rendimiento porque gestiona la infraestructura. Detectará los problemas de infraestructura. Deje el reparto por escrito en el acta de constitución y en el plan de pruebas:

1. SAP: disponibilidad de la infraestructura y respuesta a nivel de plataforma
2. Socio: rendimiento de la aplicación con la carga definida, incluidas las extensiones y los flujos de integración
3. Cliente: resultados a nivel de proceso, como la duración del cierre y el volumen de pedidos procesados, y la decisión de aceptación

La nube pública reduce el alcance

En la public edition del ERP en la nube de SAP, el sistema se ejecuta en una plataforma compartida que opera SAP. Antes de planificar cualquier prueba de carga contra un tenant, pregunte a SAP por escrito si está permitida y con cuánta antelación debe avisar.

Sus pruebas se centran entonces en lo que es suyo: integraciones a medida, extensiones, informes de gran volumen, la secuencia de cierre y el camino de red desde sus sedes. Los problemas de rendimiento de la plataforma van al soporte de SAP.

Errores frecuentes

1. Tratar las pruebas funcionales como pruebas de rendimiento. Las pruebas funcionales demuestran que una transacción da el resultado correcto. No dicen nada de 150 personas ejecutándola a la vez.
2. Dejar el rendimiento en manos de Basis. Basis es responsable del dimensionamiento y de la planificación de jobs. No lo es del diseño de los informes, de la arquitectura de los servicios OData ni del diseño de los flujos de integración, y eso es lo que determina el rendimiento de la aplicación.
3. Dar la responsabilidad solo a QA. QA ejecuta las pruebas e informa de los resultados, pero las decisiones que causan los problemas de rendimiento se toman en el diseño. Un líder de pruebas o arquitecto a nivel de programa necesita autoridad para cuestionarlas pronto, y la matriz RACI debe decir quién puede bloquear el go-live por motivos de rendimiento.
4. Aceptar los huecos como problemas conocidos. La mayoría de los programas con problemas de rendimiento en producción no se saltaron las pruebas. Probaron sin criterios acordados, o probaron y luego aceptaron los fallos bajo la presión del calendario.

Redacte los cinco o seis criterios de aceptación de sus transacciones y jobs de mayor riesgo, con un responsable con nombre para cada uno. Si no puede completar la tabla anterior, no está preparado para probar, y ha encontrado el primer hueco.

Después compruebe dos cosas: que el plan incluye un refresco de datos enmascarados a volumen de producción, y que el ciclo de concurrencia termina antes de que empiece la UAT.

Si quiere una opinión independiente sobre un plan de pruebas de rendimiento o una decisión de go-live, ayudo a las organizaciones con esto. Puede contactarme aquí.

¿Qué son las pruebas de rendimiento en SAP?

Comprueban cómo se comporta SAP con una carga realista: los tiempos de respuesta de las transacciones de usuario, la duración de los jobs en segundo plano, el volumen que procesan las interfaces y el uso de recursos cuando muchas personas trabajan a la vez. Deben hacerse antes del go-live.

La corrección funcional y el rendimiento son propiedades distintas. Una transacción correcta para un usuario puede agotar el tiempo de espera con 200.

¿Cuándo deben empezar las pruebas de rendimiento en un programa SAP?

La identificación de riesgos empieza en Explore, porque las decisiones de arquitectura determinan los resultados de rendimiento. Las pruebas activas empiezan en Realize, cuando la configuración es lo bastante estable para que los resultados tengan sentido.

Termine el último ciclo antes de la UAT, no durante ella. Los defectos de rendimiento encontrados en la UAT comprimen el calendario y crean presión para aceptarlos como problemas conocidos.

¿Cuál es la diferencia entre las pruebas de carga y las de concurrencia en SAP?

Las pruebas de carga comprueban los tiempos de respuesta con el volumen pico previsto. Las pruebas de concurrencia comprueban qué ocurre cuando muchos usuarios y jobs trabajan sobre las mismas transacciones, tablas y servicios en el mismo momento. Ahí es donde aparecen las esperas por bloqueos, las avalanchas de inicios de sesión y los cuellos de botella en el gateway.

En mi experiencia, las pruebas de concurrencia son las importantes. Ejecútelas primero y construya después la prueba de carga completa sobre ellas.

¿Qué datos de prueba deben usar las pruebas de rendimiento en SAP?

Datos enmascarados a nivel de producción. Eso significa volumen y realismo de producción, con los campos personales y sensibles enmascarados. Unos datos de prueba escasos ocultan los filtros lentos, los informes pesados y las largas duraciones de jobs que aparecen el primer día.

¿Qué herramientas se usan para las pruebas de rendimiento en SAP?

Generadores de carga como OpenText Professional Performance Engineering (antes LoadRunner Professional), Tricentis NeoLoad y Apache JMeter generan la carga. SAP Cloud ALM o SAP Solution Manager gestionan los casos de prueba y los resultados, y la monitorización del lado de SAP muestra lo que hizo el sistema bajo carga.

¿Quién es responsable de las pruebas de rendimiento en RISE with SAP?

SAP es responsable de la infraestructura: el dimensionamiento, la región, la red y la disponibilidad de la plataforma. El documento de roles y responsabilidades de RISE de SAP deja la ejecución de las pruebas de carga y el ajuste de SQL costoso en manos del cliente, salvo que se contraten SAP Cloud Application Services con cargo adicional.

El cliente y el socio son responsables del rendimiento de la aplicación y de la decisión de aceptación. Deje el reparto por escrito en los criterios de aceptación para que cada umbral tenga un responsable.