Mejores prácticas para pruebas de rendimiento

Diseñar automatizaciones de prueba fiables

Asegúrese de que los casos de prueba sean robustos, con datos estables y libres de escamas antes de escalar.

Elija estrategias de aceleración y duración

Utilice el aumento gradual para simular un tráfico realista y evitar fases pico poco realistas largas o cortas.

Gestionar datos de prueba a escala

Prepara conjuntos de datos parametrizados (a través de Data Fabric) para evitar entradas duplicadas que podrían sesgar los resultados.

Evitar errores comunes

• Asegúrese de que haya suficientes recursos de infraestructura.
• Valide las pruebas localmente antes de publicarlas.
• Utiliza las últimas versiones del paquete.

Automatización del navegador

Las siguientes recomendaciones amplían las mejores prácticas generales para las pruebas de rendimiento, específicamente para los escenarios de automatización del navegador. Las pruebas de rendimiento requieren la ejecución simultánea de varios usuarios virtuales (VU) en la misma máquina, lo que introduce restricciones que no existen en la ejecución de un solo usuario.

1. Evita las operaciones del sistema de archivos local.

   Cualquier paso que lea o escriba en un archivo local depende de los identificadores de archivos de Windows. Windows bloquea un identificador de archivo cuando un proceso lo abre, impidiendo que todos los demás procesos accedan al mismo archivo. Esto provoca fallos cuando varias VU se ejecutan simultáneamente.

   Ejemplos comunes:

   • Leer datos de prueba desde Excel o CSV : varias VU no pueden abrir el mismo archivo simultáneamente. Utilice Data Fabric en su lugar para servir datos de prueba simultáneamente sin contención de identificadores de archivos.
   • Escribir capturas de pantalla en documentos de Word : la captura de pruebas suele ser relevante solo para las pruebas funcionales y no debe formar parte de una prueba de rendimiento. En una prueba de carga, cientos de VU se ejecutan en bucles: cada iteración generaría sus propios documentos, produciendo rápidamente un volumen inmanejable de artefactos.
   • Cualquier otra interacción de archivos locales : archivos de configuración, archivos de registro, almacenes de datos intermedios: todos están sujetos al bloqueo del controlador de archivos.
2. Preferir API de Chromium: evitar eventos de hardware y Computer Vision.

   Enfoque	Descripción	Compatibilidad Multi-VU
   API de Chromium (eventos DOM simulados)	Desencadena eventos directamente en elementos DOM dentro de la instancia del navegador a través de selectores. No se produce ninguna entrada real a nivel del sistema operativo: el navegador gestiona la interacción internamente.	Excelente: independiente por instancia; funciona en ventanas en segundo plano.
   Eventos de hardware	Genera una entrada de ratón/tecla real a nivel de sistema operativo. El sistema operativo lo envía a la ventana actualmente activa (en primer plano).	Pobre: la entrada va a la ventana que está en primer plano, no necesariamente a la instancia del navegador prevista.
   Computer Vision	Localiza elementos por coincidencia de patrones visuales en pantalla.	No viable: las instancias del navegador en segundo plano son invisibles para el reconocimiento de imágenes.

3. Siempre predeterminada a la API de Chromium.

   La API de Chromium opera directamente en el DOM y funciona independientemente de si la ventana del navegador está en primer plano, minimizada u oculta.

4. Evitar eventos de hardware.

   Los eventos de hardware son enviados por el sistema operativo a la ventana activa. Con varias VU, un evento de hardware destinado a una instancia del navegador se enviará a la ventana que esté actualmente en primer plano. Los eventos de hardware no son adecuados cuando varias automatizaciones se ejecutan en paralelo en la misma máquina.

5. Evita Computer Vision.

   Computer Vision no puede interactuar con ventanas en segundo plano y, por lo tanto, es incompatible con la ejecución de varias VU. Los selectores incorrectos o ambiguos son la razón más común por la que un marco recurre a Computer Vision. Asegúrese de que los selectores sean correctos y validados durante el desarrollo. Los selectores estrictos (ID, atributos de prueba de datos, roles ARIA) funcionan bien, particularmente para aplicaciones como SAP Fiori. Los selectores difusos también son compatibles con las pruebas de rendimiento siempre que coincidan de forma fiable con el elemento previsto sin desencadenar un retroceso de Computer Vision.

6. Recomendación de simulacro

   Cuando añades un caso de prueba a un escenario de rendimiento por primera vez, la herramienta te pide que realices una ejecución de prueba. Una ejecución de prueba ejecuta varias instancias en la misma máquina para confirmar que no hay bloqueos de archivos, conflictos de entrada o problemas de selector antes de escalar a carga completa.