Pruebas de rendimiento en SAP: lo que deben saber los líderes de TI

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 con los volúmenes de producción. Empiécelas en el diseño, ejecute las pruebas de volumen y de carga en Realize cuando la configuración sea estable, termine el ciclo antes de las pruebas de aceptación de usuario (UAT) y haga que los resultados sean una condición para el cutover. Esta guía es para CIO, directores de programa y responsables de pruebas en programas S/4HANA, incluido RISE with SAP. Cubre qué probar, quién es responsable, cómo redactar criterios de aceptación y qué cambia en la nube. Empiece por la tabla de criterios de aceptación: si no puede rellenarla, no está listo para probar.

Los problemas de rendimiento en los programas SAP casi siempre se descubren después del go-live. Los mosaicos de Fiori agotan el tiempo de espera cuando 300 usuarios inician sesión en el cambio de turno. Los informes Z se congelan porque alguien lanzó una consulta del ejercicio fiscal sin límites contra una tabla con 50 millones de registros. Los jobs en segundo plano se solapan durante el cierre mensual y la ejecución de contabilización se aborta.

Los problemas de rendimiento en los programas SAP rara vez llegan por sorpresa. La mayoría eran previsibles, solo que no se planificaron. El patrón habitual: las pruebas funcionales fueron exhaustivas. Las pruebas de volumen se planificaron y después se aplazaron cuando el calendario se comprimió. Las consecuencias llegaron en las primeras semanas de operación en vivo.

No son casos extremos. Son previsibles. La única pregunta es si el programa los probó o si el negocio los 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 el resultado 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

   Pre-UAT

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

4. 04

   Cutover

   Apruebe el cutover contra los criterios de aceptación acordados de antemano, no contra la opinión.

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 significaban hacer pruebas de carga del servidor de aplicaciones y de la base de datos: tiempo de ejecución de ABAP, rendimiento de SQL, 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 (CPI), el rendimiento depende de varias capas a la vez. Un mosaico de Fiori lento podría deberse a una llamada ABAP larga, un tiempo de espera del gateway, un servicio OData no diseñado para solicitudes concurrentes o la latencia de red en una configuración híbrida. Probar solo el back end no lo encontrará. Probar la ruta completa, sí.

1. 01Apertura del mosaicoTormentas de inicio de sesión al comenzar el turno
2. 02Llamada ODataTiempos de espera del gateway, servicios no creados para la concurrencia
3. 03Procesamiento ABAPLlamadas ABAP de larga duración
4. 04Lectura de base de datosSelecciones sin límites sobre tablas grandes
5. 05RenderizadoMás la latencia de red de las sedes distantes

Un único tiempo de respuesta, medido de extremo a extremo

Las integraciones añaden su propio riesgo. Los flujos que funcionaban en desarrollo y en QA con mensajes de prueba individuales pueden encolarse o fallar en silencio con los volúmenes de producción. Si las colas de mensajes no están dimensionadas para la carga real, los retrasos se acumulan. Los síntomas parecen otra cosa: fallos intermitentes de pedidos, discrepancias de facturas, datos presentes en un sistema y ausentes en otro.

1. Las pruebas de carga comprueban el comportamiento con el volumen esperado. La palabra clave es esperado. Necesita volúmenes reales de transacciones, número de usuarios y sesiones concurrentes. Muchas pruebas de carga fracasan porque usaron estimaciones de volumen que todos sabían optimistas.
2. Las pruebas de estrés superan los límites de diseño para encontrar dónde se rompe el sistema. Si los volúmenes se duplicarán en dieciocho meses, le dicen si la arquitectura aguantará y si el dimensionamiento se convertirá en un problema antes de la próxima revisión de infraestructura.
3. Las pruebas de resistencia (soak) mantienen una carga constante durante un periodo prolongado para sacar a la luz problemas que se acumulan con el tiempo: fugas de memoria, fragmentación y contención de cadenas de jobs a lo largo de ejecuciones repetidas. Es la prueba que más se omite y la que habría detectado el fallo de cierre mensual descrito más abajo.
4. Las pruebas de extremo a extremo siguen la ruta completa que recorre un usuario: apertura del mosaico, llamada OData, procesamiento ABAP, lectura de la base de datos, renderizado. Es la única forma de encontrar problemas que son invisibles cuando cada capa se prueba por separado.

Cambio de turno y pico de inicios de sesión. Cuando 200 usuarios abren el launchpad de Fiori a las 8 de la mañana, se disparan la autenticación y el renderizado del launchpad. Un sistema que va bien fuera de hora punta puede resultar inutilizable en esa franja si nunca se probaron los inicios de sesión concurrentes. En manufactura, retail y servicios financieros, las tormentas de inicio de sesión producen las quejas más visibles del primer día.

Cierre mensual y anual. El escenario de mayor riesgo en la mayoría de los programas: contabilizaciones de gran volumen, cadenas de jobs con una secuencia estricta y un equipo de finanzas corriendo contra una fecha límite fija. Ejecute las cadenas de jobs del cierre de extremo a extremo con volúmenes del periodo de cierre, no con los promedios diarios.

Los jobs por lotes suelen probarse de forma aislada, lo que no refleja la realidad. A fin de mes, el procesamiento en segundo plano llega a su pico y muchos programas se ejecutan en paralelo sobre los mismos recursos. Un solo job mal optimizado puede bloquear otros cinco, y el cierre se pasa de su ventana.

Conversión de ECC a S/4HANA. El código estable de ECC se comporta de forma distinta en HANA. Muchos programas se vuelven mucho más rápidos; algunos producen perfiles inesperados con patrones de datos concretos. Las pruebas de regresión específicas de la conversión no son opcionales. Mi guía de migración de ECC a S/4HANA explica dónde encaja esto en el plan de conversión.

Usuarios en varias regiones. La latencia de red afecta a todas las transacciones. Un pedido de venta que tarda dos segundos en el país de alojamiento puede parecer roto a 3000 millas de distancia si nadie probó desde allí. RISE traslada el alojamiento a SAP, pero la latencia sigue dependiendo de la región que elija y del enrutamiento hacia sus usuarios.

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 aprobación	Responsable
Creación de pedidos de venta (VA01 o app de Fiori)	150 usuarios concurrentes de entrada de pedidos	Menos de 3 segundos para el 95 % de las transacciones	Responsable del proceso order-to-cash
Primera carga del launchpad de Fiori al inicio del turno	Pico de inicios de sesión concurrentes del mayor turno	Menos de 5 segundos para el 95 % de los usuarios	Responsable 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 abortos	Controller financiero
Interfaz de pedidos entrantes	Volumen horario máximo de mensajes	Ninguna cola acumulada con más de 15 minutos de antigüedad	Responsable de integración
Informe personalizado 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 debería ser lo bastante rápido para las operaciones del negocio» no se puede probar ni aceptar. Cambiar los criterios después de recibir los resultados anula el sentido de tenerlos.

Pida cada uno de estos puntos por su nombre:

Expectativa	Qué debe entregarse	Por qué importa
Niveles de servicio de rendimiento	Umbrales por transacción, interfaz y job, con criterio de superado y no superado	Evita que la opinión de la UAT se imponga a la evidencia
Alcance basado en riesgos	Priorización por volumen de usuarios, puntos de integración y dependencia de datos	Dedica los ciclos de prueba a las cargas que importan
Participación de varios equipos	Basis, infraestructura, funcional, seguridad e integración presentes durante las ejecuciones	Evita el traspaso de culpas cuando aparecen carencias
Herramientas y entornos listos	Generadores de carga (OpenText LoadRunner, Tricentis NeoLoad, Apache JMeter), monitorización y refrescos de datos preparados antes de que empiecen los ciclos	Hace realista la simulación
Datos de prueba realistas	Datos maestros con volumen de producción, llamadas reales a interfaces, mezcla representativa de transacciones	Hace que los resultados predigan el comportamiento del go-live
Informes de rendimiento	Mezcla de carga, tiempos de respuesta, CPU y memoria, duración de los jobs, tasas de error	Da una base de evidencia a la aprobación del cutover
Plan de monitorización posterior al go-live	KPI a vigilar durante los primeros 30 a 60 días	Confirma que el sistema en vivo se mantiene dentro de los límites probados

Cuatro errores aparecen con más frecuencia, incluso en grandes empresas con modelos de entrega maduros.

Tratar las pruebas funcionales como pruebas de rendimiento. Las pruebas funcionales demuestran que una transacción da el resultado correcto. No dicen nada sobre 150 personas ejecutándola a la vez.

Probar con volúmenes de datos pequeños. Un cliente con 200 000 posiciones de pedido abiertas se comporta de forma distinta a uno con 5000. Los filtros que responden al instante en pruebas agotan el tiempo en producción. Cargue volumen en las áreas de alto riesgo.

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 informes, la arquitectura de servicios OData ni el diseño de flujos de integración, y eso es lo que determina el rendimiento de la aplicación.

Dar la responsabilidad solo a QA. QA ejecuta las pruebas e informa de los resultados. Las decisiones que causan problemas de rendimiento las toman los equipos funcional, técnico y de Basis durante el diseño. Un líder de pruebas o arquitecto a nivel de programa necesita autoridad para cuestionar esas decisiones pronto, y la matriz RACI debe indicar quién puede bloquear el go-live por motivos de rendimiento.

RISE reparte la responsabilidad

Con RISE with SAP, SAP es responsable de la infraestructura: dimensionamiento, región del hiperescalador, red y disponibilidad de la plataforma. El cliente y el socio son responsables de la capa de aplicación. El documento de funciones y responsabilidades de RISE de SAP lo deja claro: encontrar y ajustar las sentencias SQL costosas sigue siendo responsabilidad del cliente, salvo que contrate los servicios de aplicación adicionales de SAP.

Un fallo común en los programas RISE es suponer que SAP detectará los problemas de rendimiento porque gestiona la infraestructura. Detectará problemas de infraestructura. No detectará un servicio OData mal diseñado, un job ABAP ineficiente ni un flujo de integración que no escala. Escriba el reparto 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

Public Edition y GROW reducen el alcance

En S/4HANA Cloud Public Edition, que normalmente se contrata mediante GROW with SAP, SAP ejecuta las pruebas de rendimiento en su plataforma multi-tenant como parte de su propio estándar de producto y no espera que los clientes hagan pruebas de carga del sistema compartido. Sus pruebas pasan a centrarse en lo que es suyo: integraciones personalizadas, extensiones, informes y analítica de gran volumen, la secuencia de cierre y consolidación, y la ruta de red desde sus sedes. Los problemas de rendimiento de la propia plataforma van al soporte de SAP.

La IA ayuda con los scripts, no con la arquitectura

Los proveedores de pruebas de carga están incorporando IA para el mantenimiento de scripts y el análisis de resultados, lo que ayuda en programas donde la aplicación cambia entre ciclos. Compruebe esas afirmaciones en su propia arquitectura antes de pagar por ellas. SAP Cloud ALM puede ayudar a generar casos de prueba y requisitos, y los asistentes de IA pueden redactar esquemas de escenarios a partir de descripciones de procesos.

Nada de eso arregla la arquitectura. La IA no le dirá que el servicio OData debió diseñarse de otra manera, ni que un informe es demasiado pesado para sus volúmenes. Esas decisiones siguen tomándolas personas, en el diseño, antes de ejecutar ninguna prueba.

La mayoría de los programas con problemas de rendimiento en producción no omitieron las pruebas por completo. Probaron sin criterios acordados, o probaron y luego aceptaron las brechas como problemas conocidos bajo presión de calendario. La disciplina está en los criterios y en hacerlos cumplir, no en la herramienta. Para ver dónde encaja el rendimiento entre otros tipos de pruebas, consulte mi comparación de herramientas de pruebas y validación de SAP y mi guía de puntos de control de calidad en SAP.

¿Qué son las pruebas de rendimiento en SAP y por qué importan?

Comprueban cómo se comporta SAP con una carga realista: tiempos de respuesta de las transacciones de usuario, duración de los jobs en segundo plano, rendimiento de las interfaces y uso de recursos con trabajo concurrente.

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. Un job que tarda diez minutos con datos de prueba puede tardar horas con volúmenes de producción. Descubrirlo después del go-live interrumpe las operaciones, obliga a cambios de emergencia y daña la confianza de los usuarios cuando la adopción es más frágil.

¿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 fijan los resultados de rendimiento. Las pruebas activas empiezan en Realize, cuando la configuración es lo bastante estable como para que los resultados signifiquen algo. Una configuración parcial da cifras engañosas.

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

¿Quién debe ser responsable de las pruebas de rendimiento en SAP?

El programa, no solo QA. QA ejecuta e informa, pero las decisiones que determinan el rendimiento se toman en el diseño entre los equipos funcional, técnico y de Basis. Un arquitecto central o un líder de pruebas del programa necesita autoridad para cuestionar esas decisiones pronto.

Déjelo explícito en la matriz RACI: quién aprueba los criterios de aceptación, quién es responsable de la corrección cuando los criterios fallan y quién puede bloquear el go-live por motivos de rendimiento.

¿Cómo cambia RISE with SAP la responsabilidad de las pruebas de rendimiento?

SAP es responsable de la infraestructura: dimensionamiento, región, red y disponibilidad de la plataforma. El cliente y el socio son responsables del rendimiento de la aplicación: configuración, extensiones, diseño de OData y Fiori, flujos de integración y KPI de proceso. El documento de funciones y responsabilidades de RISE de SAP deja el ajuste de SQL en manos del cliente, salvo que se contraten servicios adicionales de SAP.

Escriba el reparto en los criterios de aceptación para que cada umbral tenga un responsable.

¿Cuáles son los problemas de rendimiento más habituales en SAP Fiori?

Cuatro patrones cubren la mayoría. Tormentas de inicio de sesión al comenzar el turno, cuando se disparan la autenticación y el renderizado del launchpad. Servicios OData que devuelven grandes conjuntos de resultados o hacen varias llamadas al back end por interacción. La capa de gateway convertida en cuello de botella por sí misma, por lo que debe monitorizarse durante las pruebas. Y las apps personalizadas o muy modificadas, donde no se aplican los supuestos estándar de rendimiento.

¿Cómo se definen los criterios de aceptación de rendimiento en SAP?

Nombre la transacción, la carga y el umbral. Por ejemplo: «La creación de pedidos se completa en menos de 3 segundos para el 95 % de las transacciones con 150 usuarios concurrentes en el rol de entrada de pedidos». Eso se puede probar.

«El sistema debería ser lo bastante rápido» no. Acuerde los criterios con el negocio en la fase Prepare, a partir de necesidades operativas reales, y no los cambie después de recibir los resultados.

¿Qué ocurre si se omiten o se comprimen las pruebas de rendimiento?

Los problemas afloran en producción: jobs que se pasan de su ventana y bloquean otros, apps de Fiori que agotan el tiempo de espera en las horas punta, cierres mensuales que tardan el doble y no cumplen los plazos de reporte, colas de interfaces que se acumulan.

Los usuarios que se topan con problemas de rendimiento en sus primeras semanas se forman una opinión negativa del sistema que es difícil de revertir. Y la corrección de emergencia con el sistema en operación cuesta más que las pruebas, porque lo que era una decisión de diseño en Realize se convierte en un cambio de arquitectura urgente.