Pruebas de rendimiento

Las pruebas de rendimiento es un paso vital al desplegar cambios en los entornos. Para todas las pruebas del rendimiento finales, complete las pruebas en el entorno de preproducción.

Cuando empiece a implantar IBM Sterling® Order Management System, complete todas las pruebas de rendimiento y hágalas firmar como mínimo 2 semanas antes del lanzamiento de sus servicios. Este marco de tiempo garantiza que el equipo tiene tiempo de abordar cualquier problema de rendimiento que se haya encontrado durante la fase de pruebas.

Como parte de sus pruebas de rendimiento para empezar, proporcione un informe de resumen de las pruebas al equipo de operaciones de IBM Sterling Order Management System. Incluya en este informe la carga y los volúmenes máximos probados. Los volúmenes máximos y la carga deben corresponder a la volumetría prevista que figura en su declaración de trabajo de IBM Sterling Order Management System. Si el contrato se basa en "n" números de líneas de pedido en hora punta, complete la prueba de rendimiento hasta dicho límite. Si usted, o su business partner, realiza las pruebas más allá de estos volúmenes máximo contratados, asumirán todo el riesgo del rendimiento derivado de las pruebas.

Definición de un plan de pruebas

Como parte de la garantía de rendimiento de su servicio IBM Sterling Order Management System, cree planes de pruebas de rendimiento como parte de la puesta en marcha y para implementar cualquier cambio. Para crear un plan de pruebas de rendimiento, deben completarse las siguientes tareas:
  • Establecer mezclas y volúmenes de cargas de trabajo. Utilice datos de los registros del servidor web y otras herramientas para trabajar con volúmenes predichos, el crecimiento año a año, los volúmenes de horas punta predichos, etc.
    Importante: Defina y documente claramente las definiciones de volumen y carga de trabajo antes de desarrollar los scripts de carga.
  • Validar los requisitos no funcionales del cliente. Definir todos los requisitos no funcionales durante la fase de diseño.
  • Definir todos los criterios de entrada y salida para asegurarse de que el código de aplicación es estable.

Fases de pruebas y el proceso de pruebas iterativo

  1. Prueba de un único usuario
    • Análisis de código detallado
    • Longitud de vía de acceso
    • Ocupación de memoria
    • Estructura SQL básica
    • Arquitectura de aplicación
  2. Prueba de simultaneidad de sistema único
    • Sistema único
    • Gestionar mezcla de carga de trabajo completa
    • Pruebas iterativas y arreglo/ajuste
    • Establecer referencia ajustada
  3. Pruebas de escala incrementales
    • Conjunto de servidores con crecimiento incremental
    • Ajustar el único sistema.
    • Arreglo y ajuste iterativo del sistema.
  4. Pruebas de estabilidad
    • Conmutación por error
    • Ejecuciones largas
El siguiente diagrama muestra el proceso de ajuste y pruebas iterativo de alto nivel.
Imagen que muestra el proceso de prueba iterativo.
  • Línea base
    • Qué hace el sistema ahora
    • Fundamental para medir la mejora
  • Ajuste mínimo
    • Limitar el cambio entre ejecuciones
  • Prueba
    • Duración suficiente
    • Medida en estado estable
  • Observar
    • Examinar todos los sistemas y registros
    • Anotar resultados
    • Plan para prueba siguiente

Entornos de prueba, datos y responsabilidades para el ajuste funcional y del rendimiento

  Responsabilidad Entorno Datos
Prueba de unidad Equipo de implementación Entorno de kit de herramientas de desarrollador Simulados
Pruebas de función Equipo de implementación Control de calidad Simulados
Pruebas de aceptación de usuarios Usted o el equipo de servicios de su business partner Preproducción y producción
Control de calidad *		 Datos empresariales válidos
Pruebas de rendimiento Usted o el equipo de servicios de su business partner Control de calidad (pruebas de rendimiento iniciales)
Preproducción (con DynaCache habilitado)		 Datos empresariales válidos
Pruebas de migración tras error de componentes Equipo de implementación Producción Datos empresariales válidos
* Las pruebas de aceptación de usuario funcionales se pueden realizar en el entorno de control de calidad si los datos del entorno de producción no están listos para su uso en las pruebas.
Complete cualquier creación de perfiles de aplicación dentro del entorno del kit de herramientas del desarrollador, como por ejemplo cuando realice las tareas siguientes:
  • Creación de perfiles de código Java para identificar la funcionalidad o los módulos con bajo rendimiento, o para identificar ineficiencias en diseños y código.
  • Análisis y rastreo de SQL para rastrear actividad SQL y aislar y revisar los cuello de botella de rendimiento de SQL.
  • Verificación de la implementación de DynaCache para garantizar que toda la funcionalidad que puede almacenarse en memoria caché se está almacenando en memoria caché de forma precisa y efectiva
  • Creación de perfiles de código de JavaScript para identificar fuga de memoria e ineficiencias en diseños y código.
  • Solicitar análisis para identificar peticiones duplicadas o innecesarias.